Optymalizacja rozproszonej bazy danych w eksperymencie Pi of the Sky

Transkrypt

1 UNIWERSYTET KARDYNAŁA STEFANA WYSZYŃSKIEGO W WARSZAWIE WYDZIAŁ MATEMATYCZNO-PRZYRODNICZY SZKOŁA NAUK ŚCISŁYCH Michał Wójcik numer albumu : Informatyka i Ekonometria Optymalizacja rozproszonej bazy danych w eksperymencie Pi of the Sky Praca magisterska wykonana pod kierunkiem naukowym prof. UKSW dr hab. Jerzego Cytowskiego WARSZAWA 2008

2

3 WPROWADZENIE SZYBKOZMIENNE OBIEKTY ASTROFIZYCZNE HISTORIA ODKRYCIA I BADAŃ ZWIĄZANYCH Z BŁYSKAMI GAMMA INNE SZYBKOZMIENNE OBIEKTY ASTROFIZYCZNE EKSPERYMENT PI OF THE SKY APARATURA UśYWANA W EKSPERYMENCIE ZBIERANIE I PRZETWARZANIE DANYCH SYSTEMY BAZ DANYCH BAZY DANYCH MODELE DANYCH UśYWANE W SYSTEMACH BAZ DANYCH RELACYJNE BAZY DANYCH SYSTEMY BAZ DANYCH UśYWANE W EKSPERYMENCIE PI OF THE SKY DLACZEGO IBM DB2? BAZA DANYCH W EKSPERYMENCIE PI OF THE SKY TABELE WCHODZĄCE W SKŁAD BAZY PI OF THE SKY KATALOG GWIAZD ROZMIARY BAZY DANYCH ROZPROSZONA BAZA DANYCH CECHY ROZPROSZONEGO SYSTEMU ŚRODOWISKO TESTOWE SPOSÓB ROZPROSZENIA DANYCH W TABELACH TESTOWANIE WYDAJNOŚCI ZAPYTAŃ METODOLOGIA TESTÓW DANE DO TESTÓW TESTOWANIE CZASU WYKONANIA ZAPYTAŃ WNIOSKI PODSUMOWANIE DODATEK A PODZIĘKOWANIA BIBLIOGRAFIA

4 Wprowadzenie Ideą eksperymentu π of the Sky są badania zjawisk astrofizycznych z duŝa rozdzielnością czasową, w szczególności obserwacje optycznych odpowiedników błysków promieniowania gamma (ang. Gamma Ray Burst GRB). Prototyp systemu został w czerwcu 2004 roku zainstalowany w Las Campanas w Chile. Składa się on z dwóch kamer CCD o rozdzielczości 2000 x 2000 pikseli wyposaŝonych w obiektywy firmy Canon o ogniskowej 85mm. Prototyp ten jest w uŝyciu do dnia dzisiejszego. Dane zebrane w czasie trwania tego etapu eksperymentu zostały wykorzystane podczas tworzenia pracy. W docelowej fazie aparaturę będą stanowiły dwa zestawy po 16 kamer. Oba zestawy obserwujące ten sam fragment nieba umieszczone będą w znacznej odległości od siebie. Pozwoli to na wyeliminowanie nieinteresujących błysków optyki, spowodowanych przejściem promieni kosmicznych lub odblaskami światła słonecznego od sztucznych satelitów lub samolotów. DuŜa liczba kamer w zestawie pozwoli na jednoczesną obserwację znacznego fragmentu nieba. Do tej pory uŝywanym systemem bazodanowym obsługującym dane pochodzące z kamer uŝywany był PostgreSQL, który spełniał większość wymagań dotyczących przechowywania i obsługi danych. System ten jednak będzie niewystarczający w momencie, gdy zostanie uruchomiony system składający się z 32 kamer obserwujące niebo. W związku z tym konieczne było zastosowanie komercyjnej wersji systemu zarządzania bazą danych, która byłaby w stanie sprostać wymaganiom przetwarzania ogromnych ilości danych (ponad 15GB danych dziennie) z zachowaniem zdolności do utrzymywania parametrów operacyjnych na tym samym poziomie w miarę ciągłego rozwoju systemu. W Warszawie, dnia 3 marca 2008 r. firma IBM Polska przekazała do uŝytku Instytutowi Problemów Jądrowych im. Andrzeja Sołtana, w ramach programu IBM Academic Initiative, najnowocześniejszą bazę danych IBM DB2 Enterprise 9.5. Moim głównym zadaniem, stanowiącym temat tej pracy, było testowanie wydajności przez skonfigurowanie rozproszonego środowiska bazodanowego oraz optymalizacja jego parametrów, w celu uzyskania wzrostu efektywności przetwarzania. Porównanie wydajności na środowisku testowym obu systemów zrealizowane zostało poprzez zmierzenie czasu wykonania specjalnie do tego celu przygotowanych zapytań SQL pochodzących z aktualnie funkcjonujących aplikacji korzystających z informacji pochodzących z bazy danych. Plan pracy jest następujący. W rozdziale 1 przedstawione zostały szybkozmienne procesy astrofizyczne, których badaniem zajmuje sie eksperyment Pi of the Sky. W rozdziale 2 zaprezentowane są informacje o eksperymencie: uŝywanej aparatury oraz danych, które są zbierane i przetwarzane. Rozdział 3 opisuje przeznaczenie i historię powstania baz danych oraz krótką charakterystykę systemów bazodanowych uŝywanych w eksperymencie. Rozdział 4 przedstawia struktury, w jakich zapisywane są dane pochodzące z eksperymentu. W rozdziale 5 zostały umieszczone informacje o metodach rozproszenia dostępnych w nowym systemie oraz opis konfiguracji środowiska testowe. W rozdziale 6 pokazane zostały wyniki przeprowadzonych testów na rozproszonym środowisku. Dodatek A zawiera informacje o skryptach, za pomocą których moŝna ponownie przeprowadzić testy. 4

5 1 Szybkozmienne obiekty astrofizyczne Współczesna astronomia poznała wiele przykładów krótkotrwałych procesów astrofizycznych. Jednym z nich są błyski promieniowania gamma (ang. Gamma Ray Burst - GRB) pojawiające się w całym obszarze sfery niebieskiej 2-3 razy na dobę i trwające od kilku sekund aŝ do godziny, krótkie błyski promieniowania gamma pochodzące z punktowych źródeł na niebie. Przyczyna długich błysków gamma nie jest do końca poznana najprawdopodobniej są to nagłe eksplozje mające związek z ostatnią fazą rozwoju gwiazdy. Występują one na krańcach obserwowanego Wszechświata, o czym świadczą ich duŝe przesunięcia ku czerwieni. W wyniku eksplozji emitowane jest promieniowanie gamma, a ich obserwowana jasność i olbrzymia odległość powodują, Ŝe rozbłyski gamma są największymi wybuchami we Wszechświecie znanymi współczesnej astronomii. 1.1 Historia odkrycia i badań związanych z błyskami gamma Historia odkrycia błysków sięga początku lat 60. XX w. W czasach Zimnej Wojny dwa mocarstwa światowe USA oraz Związek Radziecki prowadziły badania nad produkcją nowoczesnych broni masowego raŝenia. Prowadziło to do zwiększenia zagroŝenia związanego z wybuchem wojny nuklearnej. W 1963 roku podpisany został pakt zakazujący prób nuklearnych w atmosferze, wodzie i kosmosie (Treaty Banning Nuclear Weapon Tests In The Atmosphere, In Outer Space And Under Water, zwany równieŝ Partial Test Ban Treaty PTBT). Pakt ten dopuszczał jedynie podziemne próby nuklearne. Wśród państw, które go podpisały były między innymi USA i ZSRR. Amerykańskie satelity szpiegowskie Vela1 i Vela2 zostały wystrzelone w 1963 roku, a ich celem było monitorowanie Ziemi i bliskiej przestrzeni kosmicznej w poszukiwaniu sygnałów świadczących o przeprowadzaniu prób atomowych. Podczas wybuchu jądrowego około połowa wszystkich fal wypromieniowywane jest w długościach rentgenowskich, natomiast tylko jeden procent w długościach gamma, więc sposobem kontroli stało się wysłanie w kosmos odpowiednich detektorów. Właśnie w detektory promieniowania gamma i X zostały wyposaŝone satelity szpiegowskie Vela. Jednak technologia wtedy zastosowana ograniczała moŝliwości detektorów do wyznaczenia natęŝenia promieniowania, czasu i przybliŝonego kierunku. Technologia detektorów była stale rozwijana i po kilku latach zostały w przestrzeń wysłane kolejne satelity z detektorami, które były w stanie wyznaczać źródła błysków z dokładnością do 5 stopni. 5

6 Rysunek 1 - pierwsze modele satelitów Vela (źródło Naukowcy z Los Alamos National Laboratory porównywali dane pochodzące z satelitów, aby szukać koincydencji pomiędzy rejestracjami rozbłysków promieniowania gamma, gdyŝ jedynie ta metoda selekcjonowania mogła odrzucić przypadkowe wyładowania pochodzące ze Słońca, czy kosmosu. Znaleziony został jeden bardzo ciekawy przypadek pochodzący z drugiego lutego 1967 roku wtedy to satelity Vela 4a i Vela 4b zarejestrowały silny sygnał w zakresie promieniowania gamma. Pojawiło się podejrzenie, Ŝe ZSRR złamało traktat, lecz kształt zarejestrowanego błysku zdecydowanie róŝnił się od tego, jaki otrzymywany jest po wybuchu bomby atomowej. W przypadku broni jądrowej satelita powinien zaobserwować pojedynczy błysk, natomiast ten zarejestrowany drugiego lutego miał charakterystyczny, dwugarbny kształt. Dokładna analiza kształtu sygnału wyeliminowała eksplozję jądrową jako potencjalne źródło promieniowania. Błysk ten został zakwalifikowany jako błysk pochodzenia kosmicznego. Istnienie błysków gamma zostało potwierdzone przez rosyjskiego satelitę szpiegowskiego Konus. Następnie zaczęto poszukiwać podobnych błysków wśród danych zgromadzonych przez satelitę. W latach zarejestrowano 16 nowych błysków. Początkowo spodziewano się, Ŝe błyski te związane są w pewien sposób z wybuchami na Słońcu, jednak z danych wynikało, ze błyski pochodzą z odległego obiektu (ponad 1 mln kilometrów), ale nie ze Słońca, KsięŜyca, ani z Ŝadnej planety. Podejrzewano, ze pochodzą spoza Układu Słonecznego. Wszystkie te dane zostały przeanalizowane i podane do publicznej wiadomości w czasopiśmie Astrophysical Journal w 1973 roku i wtedy właśnie powstała nazwa Gamma Ray Burst (GRB) określająca ten typ błysków. 6

7 Rysunek 2 - Pierwszy wykryty błysk gamma pochodzenia kosmicznego, zarejestrowany w dniu r. (źródło Kolejne lata przyniosły rozwój badań nad GRB. Wystrzelono satelity wyspecjalizowane do obserwacji tych zjawisk. W roku 1991 NASA wysłała satelitę zaopatrzonego w instrument BATSE (Burst And Transient Source Experiment). Wielkim atutem BATSE było zdolność do wyznaczania pozycji błysku z precyzją rzędu jednego stopnia. Niektóre błyski zaobserwowane przez instrument trwały kilka sekund, inne kilka minut. Błyski te róŝniły się krzywą blasku: ich jasność gwałtownie spadała lub teŝ wygaszały się wolniej. KaŜdy z zarejestrowanych błysków wyglądał inaczej, nie znaleziono wśród nich powtarzalności. Przełomem w badaniach było opublikowanie przez NASA mapy pozycji wszystkich zarejestrowanych przez BATSE błysków. Błyski te nie były skoncentrowane w Ŝadnym obszarze, a rozkładały się równomiernie (izotropowo) po całym niebie. To wskazywało na ich pozagalaktyczne pochodzenie. W ciągu dziewięciu lat działania BATSE wykryto i zlokalizowano 2704 wybuchy gamma. Rysunek 3 - rozkład izotopowy błysków gamma (źródło 7

8 W 1996 roku na orbitę okołoziemską z Przylądka Canaveral został wystrzelony włosko-holenderski satelita Beppo-SAX (Beppo od pseudonimu jednego z twórców, SAX wł. Satellite per Astronomia a raggi X). Oprócz detektorów promieniowania gamma został on wyposaŝony w teleskop dla nisko- i średnio-energetycznego promieniowania rentgenowskiego oraz detektor przeznaczony do badania wyjątkowo silnych wiązek tego promieniowania. Dwudziestego ósmego lutego 1997 roku Beppo-SAX zarejestrował błysk GRB (tj. błysk gamma z 28 lutego 1997 roku zgodnie z oznaczeniami błysków gamma) i przesłał informację o nim do obserwatoriów naziemnych. Udało sie zaobserwować towarzyszącą błyskowi poświatę zarówno radiową jak i optyczną. Kolejny zaobserwowany błysk z dnia 8 maja 1997 przyniósł jeszcze więcej informacji udało się po raz pierwszy w historii zmierzyć przesunięcie ku czerwieni poświaty pozostałej po błysku dzięki temu oszacowano odległość od źródła na 7 mld lat świetlnych. Biorąc pod uwagę moc sygnału, który został zarejestrowany na Ziemi, całkowita ilość energii wyemitowana w wybuchu została oszacowana na 10 mld lat ciągłego świecenia Słońca. Potwierdzone zostało pozagalaktyczne pochodzenie GRB. Rysunek 4 - satelita Beppo-SAX (źródło Kolejną kwestią do rozwiązania było określenie, co jest źródłem tak olbrzymich energii. Polski naukowiec prof. Bohdan Paczyński wysunął wniosek, Ŝe GRB są związane z gwałtowną śmiercią bardzo masywnych gwiazd i zaproponował nadaniu temu zjawisku nazwy hipernowych. Po dostarczeniu danych przez satelitę Beppo-SAX okazało się, Ŝe kluczem do rozwiązania zagadnienia powstawania GRB są obserwacje w innych długościach fali: widzialnych, podczerwonych, radiowych. Pomiary spektroskopowe pozwalają wyznaczyć nie tylko przesuniecie ku czerwieni, a więc odległość od źródła, ale takŝe linie widmowe poszczególnych składników źródła. Dzięki temu moŝliwe jest wyznaczenie jego składu chemicznego. Wykrycie GRB przy pomocy fal widzialnych jest bardzo trudne błysk jest krótkotrwały i mała część energii jest emitowana w tych długościach fali. Dlatego potrzebne jest współdziałanie teleskopów optycznych z satelitarnymi detektorami promieniowania 8

9 gamma (naziemne detektory gamma są nieskuteczne, gdyŝ promieniowanie wysokoenergetyczne jest pochłaniane przez atmosferę). Jednym z eksperymentów naziemnych mających moŝliwość szybkiej zmiany kierunku obserwacji na podstawie danych przesyłanych przez satelity był ROTSE (ang. Robotic Optical Transient Search Experiment). Gdy 23 stycznia 1999 roku ROTSE dostał sygnał z satelity Beppo-SAX o połoŝeniu błysku, jego kamery zlokalizowały obszar GRB i odnalazły błysk optyczny juŝ po 22 sekundach. UmoŜliwiło to po raz pierwszy w historii pełną analizę widma optycznego zaraz po błysku. Obserwacja błysku, który 11 grudnia 2001 roku został zlokalizowany przez satelitę rentgenowskiego XMM-Newton (ang. X-ray Multi-Mirror) zbudowanego przez Europejską Agencję Kosmiczną, takŝe przyniosła wiele informacji na temat składu chemicznego wyemitowanej materii. Analiza linii widomych pozwoliła na wyodrębnienie duŝych ilości takich pierwiastków jak magnez, krzem, siarka, argon oraz wapń i stosunkowo mało Ŝelaza. Podobny skład ma materia emitowana podczas wybuchu supernowej. Dzięki tym odkryciom zaczęto przywiązywać wagę do szybkości przekazywania informacji od satelity do obserwatoriów naziemnych. Satelita HETE2 (ang. High Energy Transient Explorer), wystrzelony przez NASA w 2000 roku, miał moŝliwość przekazywania informacji o błysku juŝ w sek. po jego zauwaŝeniu. Rysunek 5 - satelita HETE2 (źródło Po 10 latach przygotowań i testów, w których uczestniczyły instytucje z wielu krajów Europy oraz ze Stanów Zjednoczonych, w 2002 roku z Kosmodromu Bajkonur (Kazachstan, Rosja), został wystrzelony na orbitę satelita Integral (ang. International Gamma Ray Astrophysics Laboratory) posiadający na pokładzie cztery urządzenia pomiarowe. 9

10 Rysunek 6 - satelita Integral (źródło Dwudziestego listopada 2004 roku wystartowała sonda SWIFT - pierwsze satelitarne wielozakresowe orbitalne obserwatorium przeznaczone do badań rozbłysków promieniowania gamma. Satelita ten wyposaŝony został w bardzo czułe detektory promieniowania gamma. Na jego pokładzie znajdują się trzy instrumenty: 1. BAT (ang. Burst Alert Telescope) detektor słuŝący do wykrywania wybuchów 2. XRT (ang. X-Ray Telescope) detektor promieniowania X 3. UVOT (ang. Ultraviolet/Optical Telescope) teleskop optyczny pracujący w zakresie widzialnym i ultrafioletu Dzięki temu błyski mogą być obserwowane w prawie całym zakresie widma elektromagnetycznego. Satelita SWIFT lokalizuje i obrazuje błyski gamma szybciej niŝ Integral. PoniewaŜ większość błysków trwa nie dłuŝej niŝ przez 10 sekund, a nieliczne ponad minutę, więc szybkość wykonania obserwacji i przekazanie informacji do obserwatoriów naziemnych, w celu skierowania teleskopów w miejsce błysku, ma kluczowe znaczenie dla zrozumienia błysków. Rysunek 7 - satelita SWIFT (źródło 10

11 Wszystkie informacje pochodzące z krąŝących satelitów oraz naziemnych teleskopów dotyczące GRB trafiają do koordynacyjnej sieci obserwacji rozbłysków gamma nazywanej GCN (ang. The Gamma Ray Bursts Coordinates Network). Rozsyła ona informacje o nowych błyskach zarejestrowanych przez satelity, a takŝe komunikaty dotyczące obserwacji tych błysków przez obserwatoria naziemne. PoniewaŜ informacja pochodząca z satelity przesyłana jest natychmiastowo do wszystkich uŝytkowników sieci, duŝe teleskopy naziemne, mające małe pole widzenia, mogą przemieścić się po takim sygnale do odpowiedniej pozycji, która pozwoli na obserwację optycznej poświaty pozostawionej przez błysk gamma, bądź teŝ samego błysku. Sieć GCN zrzesza praktycznie wszystkie liczące się obserwatoria GRB. Eksperyment Pi of the Sky równieŝ do niej naleŝy. Rysunek 8 - sieć GCN (źródło Inne szybkozmienne obiekty astrofizyczne Do innych szybkozmiennych obiektów astrofizycznych obserwowalnych przez aparaturę Pi of the Sky moŝna zaliczyć: Wybuchy gwiazd nowych Wybuchy supernowych Gwiazdy zmienne Blazary i aktywne jądra galaktyk (ang. Active Galactic Nuclei AGN) 11

12 2 Eksperyment Pi of the Sky Eksperyment Pi of the Sky jest prowadzony przez zespół pracowników naukowych i studentów warszawskich uczelni i placówek naukowych. Celem eksperymentu jest obserwacja szybkozmiennych zjawisk astrofizycznych o skalach czasowych 10 sek., poszukiwania i badania błysków optycznych, stowarzyszonych z rozbłyskami gamma (GRB) oraz pozostawionych po nich poświat. Motywacją do powstania eksperymentu było badanie błysków gamma, a dokładniej poszukiwanie optycznych poświat tych błysków. Głównym celem eksperymentu obserwacja GRB od samego początku błysku gamma a nawet przed. Zarejestrowanie widzialnej poświaty juz w czasie trwania błysku lub nawet wcześniej dostarczyłoby cennych danych o przebiegu takiego zjawiska. Aparatura eksperymentu jest obecnie umieszczona w obserwatorium Las Campanas w Chile. Miejsce to zostało wybrane ze względu na jego klimat i ukształtowanie terenu. Powietrze jest tam czyste i przejrzyste, dzięki czemu przez prawie cały rok moŝna dokonywać obserwacji nieba. Dodatkowym autem jest brak wielkich miast pozostawiających poświatę w czasie nocy. W tym samym miejscu są równieŝ umieszczone zaprzyjaźnione polskie eksperymenty astronomiczne zajmujące się badaniem gwiazd zmiennych: ASAS (ang. All-Sky Automated Survey) i OGLE (ang. The Optical Gravitational Lensing Experiment). Cechy eksperymentu: Ciągłe obserwacje duŝego wycinka nieba odpowiadającego polu widzenia satelity SWIFT lub GLAST KaŜdy błysk zaobserwowany przez te satelity będzie od razu w polu widzenia kamer eksperymentu bez konieczności ruchu teleskopu (czas reakcji < 0 sek.) Własny system identyfikacji błysków optycznych i innych krótko-zmiennych procesów astrofizycznych Lokalizacja w dwóch miejscach odległych o kilkadziesiąt/set kilometrów (w docelowej fazie) 2.1 Aparatura uŝywana w eksperymencie Pod koniec czerwca 2004 roku prototypowy zestaw dwóch kamer CCD o rozdzielczości 2000 x 2000 pikseli wyposaŝonych w obiektywy Carl Zeiss o ogniskowej 50 mm zainstalowano w obserwatorium Las Campanas w Chile. Pracował on do lipca 2005 roku. W ciągu tej fazy eksperymentu zrobiono ponad 600 tys. zdjęć nieba. Doświadczenie zdobyte w tym czasie pozwoliło na dalsze ulepszenie kamer, montaŝu i metod zbierania danych. W maju 2006 kamery zostały wyposaŝone w obiektywy CANON o ogniskowej 85 mm i polu widzenia 28 x 28 stopni. Elektronika układu została skonstruowana tak, aby odczyt danych następował z bardzo duŝą prędkością wynoszącą 2 Mpiksele/sekundę, dzięki czemu czas odczytu całej matrycy trwa 2 sekundy. Wzmocniony analogowy sygnał pochodzący z matrycy CCD przechodzi przez przetwornik analogowo-cyfrowy i zapisywany jest w pamięci komputera poprzez złącza USB. Podstawowym trybem pracy aparatury eksperymentu jest obserwacja duŝego wycinka nieba. W przypadku otrzymania z sieci GCN sygnału o prawdopodobnym błysku gamma, kamery podąŝają do wskazanego miejsca na niebie. W czasie obserwacji nieba montaŝ obraca kamery tak, aby kompensowały ruch dobowy Ziemi. 12

13 Rysunek 9 - prototyp w LCO w Chile (źródło Strategia obserwacji (prototyp umieszczony w LCO) Śledzi pole widzenia satelitów SWIFT i INTEGRAL, reaguje na zawiadomienia wysyłane przez GCN JeŜeli Ŝaden z satelitów nie moŝe być obserwowany, wybierany jest alternatywny interesujący obiekt z listy Klatki 10 sekundowe Dwa razy na noc wykonywany jest skanowanie dostępnego nieba 2.2 Zbieranie i przetwarzanie danych Otrzymane z obserwacji zdjęcia są analizowane w czasie rzeczywistym pod względem poszukiwania błysków o czasie narastania rzędu kilku sekund. Algorytm uŝywany do poszukiwań błysków polega na porównywaniu nowej klatki z serią poprzednich klatek i wykrycia na niej nowych obiektów. Oczywiście w pierwszej fazie poszukiwań błysków znajdowane są wszelkiego rodzaju przypadki tła (w tej fazie liczba znalezionych błysków sięga rzędu 10 9 ), lecz juŝ Ŝądanie koincydencji z obu kamer zmniejsza liczbę kandydatów o cztery rzędy wielkości. Następne zmniejszenie liczby interesujących przypadków odbywa się poprzez porównanie błysków z katalogiem znanych satelitów i gwiazd stałych oraz wyznaczenie torów lotu na podstawie przypadków z wielu kolejnych klatek. Po tych operacjach liczba znalezionych błysków zmniejsza się z początkowych kilku miliardów do kilkunastu interesujących przypadków. Algorytmy analizujące dane w czasie rzeczywistym nazywane są algorytmami on-line. Nawet zdjęcia, na których nie wykryto nagłych zmian jasności, są źródłem informacji dotyczących np. zmienności gwiazd. Nie jest moŝliwe przechowywanie wszystkich zdjęć 13

14 dane zebrane w ciągu nocy zajmują około 50GB, a w docelowej fazie eksperymentu danych tych moŝe być nawet 16 razy więcej. Dodatkowym utrudnieniem byłaby analiza tak duŝej ilości danych dostarczanych codziennie. Aby rozwiązać oba problemy dane są redukowane w celu wyodrębnienia najwaŝniejszych informacji, czyli przede wszystkim jasności gwiazd. Przygotowanie zdjęcia do analizy odbywa się przez odjęcie tzw. ciemnej klatki (zdjęcie przy zamkniętej przesłonie) i podzielenie przez klatkę flat (zdjęcie jednorodnie oświetlonego obszaru nieba). Następnie na takim wstępnie przetworzonym zdjęciu najpierw przeprowadzana jest fotometria, czyli znajdowanie gwiazd na zdjęciu i ustalanie jasności oraz współrzędnych na matrycy CCD (w pikselach). W celu zwiększenia dokładności, fotometria jest dodatkowo przeprowadzana na sumach dwudziestu dodanych do siebie cyfrowo kolejnych klatek. W ten sposób redukowany jest wpływ szumu elektroniki. Fotometria na sumach klatek pozwala znaleźć i dokładnie zmierzyć jasność gwiazd o rząd wielkości ciemniejszych niŝ w przypadku fotometrii na pojedynczych klatkach, gdzie słabe gwiazdy giną w szumie elektroniki. Kolejnym krokiem redukcji danych jest astrometria, czyli odwzorowanie współrzędnych zdjęcia na współrzędne niebieskie. Jest to robione przy pomocy referencyjnych gwiazd stałych - na zdjęciu znajdowane są najpierw gwiazdy. Następnie za pomocą dopasowania powierzchni trzeciego stopnia ze współrzędnymi tych gwiazd jako punktami kontrolnymi, tworzone jest odwzorowanie. Jako referencyjne gwiazdy wybrano te, które skatalogował satelita Hipparcos. Katalog zawiera prawie 120 tys. gwiazd, a oprócz połoŝeń znane są takŝe paralaksy. Na podobnej zasadzie konstruuje sie odwzorowanie jasności. W ten sposób liczone są współrzędne niebieskie oraz jasności w skali wielkości gwiazdowej (magnitudo) dla wszystkich gwiazd ze zdjęcia. Wszystkie te informacje są zapisywane do bazy danych, a całe zdjęcie jest przechowywane tylko przez kilka kolejnych dni. Ten etap nazwany został katalogowaniem. Algorytmy działające na danych zapisanych w bazie noszą nazwą algorytmów off-line. 14

15 3 Systemy baz danych 3.1 Bazy danych Czym są bazy danych? Bazy danych odgrywają w dzisiejszych czasach istotną rolę we wszystkich działaniach gospodarczych. SłuŜą do przechowywania danych przedsiębiorstwa, do prezentowania danych klientom poprzez strony internetowe oraz do wspierania szerokiej gamy innych działań biznesowych. Baza danych to uporządkowany zbiór informacji (danych) z określonej dziedziny lub tematyki, zapisanych w ściśle określony sposób w strukturach odpowiadających załoŝonemu modelowi danych. W potocznym ujęciu obejmuje dane oraz oprogramowanie komputerowe wyspecjalizowane do gromadzenia i przetwarzania tych danych. Oprogramowanie te nazywane jest "Systemem zarządzania bazą danych" (z ang. DataBase Management System, DBMS). Właśnie o sile baz danych stanowią wiedza i technologia, rozwijane przez długi czas i skupione w specjalnie w tym celu stworzonym oprogramowaniu DBMS. Formalnie termin baza danych oznacza zbiór danych, który zarządzany jest przez DBMS. Bazy danych operują głównie na danych tekstowych i liczbowych, lecz większość współczesnych systemów bazodanowych umoŝliwia przechowywanie takŝe danych multimedialnych, takich jak zdjęcia czy filmy, oraz danych zapisanych w specjalnych formatach, np. XML Oczekiwania wobec DBMS DBMS stanowi mocne narzędzie przeznaczone do tworzenia i zarządzania ogromnymi zbiorami danych oraz bezpiecznego przechowywania ich przez długi czas. W chwili obecnej DBMS są jednymi z najbardziej złoŝonych typów dostępnego oprogramowania. Główne oczekiwania wobec systemów zarządzania bazą danych to: 1. UmoŜliwienie uŝytkownikowi utworzenia nowej bazy danych i określenia jej schematu (logicznej struktury danych) za pomocą specjalizowanego języka definiowania danych 2. Udostępnienia uŝytkownikowi moŝliwości tworzenia zapytań o dane oraz aktualizowania danych za pomocą odpowiedniego języka zapytań 3. Zapewnienia moŝliwości przechowywania ogromnej ilości danych przez długi czas, ochrony przed przypadkowym lub nieautoryzowanym dostępem, a takŝe umoŝliwienia efektywnego dostępu do tych danych za pomocą języka zapytań i operacji na danych 4. Sterowania jednoczesnym dostępem do danych przez wielu uŝytkowników, z zapewnieniem bezkolizyjności działania oraz ochrony danych przed przypadkowym uszkodzeniem lub usunięciem MoŜliwości DBMS Do najwaŝniejszych moŝliwości systemu zarządzania bazą danych moŝna zaliczyć: 1. Pamięć trwałą: DBMS, tak samo jak system plików, udostępnia pamięć do przechowywania duŝych ilości danych, istniejących niezaleŝnie od procesów, które z tych danych korzystają. DBMS przewyŝsza jednak moŝliwości standardowego systemu plików pod względem elastyczności operowania na 15

16 danych, dzięki dostarczeniu specyficznych struktur danych, które umoŝliwiają szybki i bezpieczny dostęp do zbiorów danych. 2. Interfejs programisty: DBMS udostępnia uŝytkownikowi lub aplikacji język zapytań, dzięki któremu uzyskuje się dostęp do danych oraz moŝliwości ich modyfikacji. DBMS przewyŝsza standardowy system plików, poniewaŝ umoŝliwia wykonywanie bardziej skomplikowanych działań na danych niŝ ich tylko zapisywanie i odczytywanie. 3. Zarządzanie transakcjami: DBMS zapewnia jednoczesny dostęp do danych, tzn. wiele róŝnych procesów (zwanych transakcjami) jednocześnie uzyskuje dostęp. Aby uniknąć niepoŝądanych skutków jednoczesnych operacji, DBMS zapewnia izolację, tj. wykonanie kaŝdej transakcji tak, jakby pozornie wykonywała się tylko jedna w danym momencie, oraz niepodzielność wymaganie, aby transakcja wykonała się albo w całości, albo wcale. DBMS zapewnia teŝ trwałość, czyli zdolność do naprawy róŝnego rodzaju błędów i uszkodzeń oraz spójność danych oznaczającą, Ŝe po wykonaniu transakcji system będzie spójny, czyli nie zostaną naruszone Ŝadne zasady integralności. Cechy te w skrócie noszą nazwę ACID (z ang.): A atomicity (niepodzielność) C consistency (spójność) I isolation (izolacja) D durability (trwałość) Historia rozwoju baz danych Najwcześniejsze znane uŝycie terminu baza danych miało miejsce w listopadzie 1963, kiedy odbywało się sympozjum pod nazwą "Development and Management of a Computercentered Data Base", sponsorowane przez System Development Corporation. Termin zaczął być powszechnie uŝywany w Europie na początku lat siedemdziesiątych XX wieku, a w Ameryce do końca tej dekady. Pierwszy DBMS został opracowany w latach sześćdziesiątych XX wieku. Pionierem był Charles Bachman. Opracowania Bachmana pokazywały, Ŝe jego celem było efektywniejsze uŝycie nowych urządzeń bezpośredniego dostępu do składowanych danych, które wtedy zaczynały być dostępne. Do tej pory przetwarzanie danych oparte było na kartach dziurkowanych oraz taśmach magnetycznych. Oznaczało to szeregowy dostęp do danych, co implikowało uŝycie innych algorytmów niŝ dla dostępu swobodnego. Wtedy to powstały dwa kluczowe modele danych: sieciowy, opracowany przez CODASYL na bazie pomysłu Bachmana i hierarchiczny, uŝyty w systemie opracowanym przez North American Rockwell i później adoptowany przez IBM jako kamień milowy dla IMS. W tym czasie, oprócz CODASYL IDMS i IMS, powstały takŝe inne bazy danych. Przykłady to PICK i MUMPS opracowane wcześniej jako systemy operacyjne z wbudowanymi bazami danych, a potem językami programowania i bazami danych do stosowania w systemach opieki zdrowotnej. W roku 1970 Edgar Frank Codd zaproponował relacyjny model danych. Krytykował on istniejące w tamtym czasie modele danych za mieszanie abstrakcyjnego opisu struktury informacyjnej z opisami mechanizmów fizycznego dostępu. Przez dłuŝszy czas jego model relacyjny pozostawał tylko w sferze rozwaŝań akademickich. Podczas gdy produkty CODASYL (IDMS) i IBM (IMS) były uwaŝane za praktyczne rozwiązania dostępnych technologii, to model relacyjny musiał wtedy poczekać na odpowiedni poziom rozwoju oprogramowania i sprzętu. Pierwszymi implementacjami modelu relacyjnego były: Ingres Michaela Stonebrakera z Berkeley i System R z IBM. Oba były prototypami badawczymi, ogłoszonymi w roku Komercyjne rozwiązania, Oracle i IBM DB2 pojawiły się około 16

17 roku Natomiast pierwszym udanym produktem tego typu dla mikrokomputerów był dbase dla systemów operacyjnych CP/M i PC-DOS/MS-DOS. W latach osiemdziesiątych XX wieku, aktywność naukowców skupiała się na rozproszonych bazach danych i maszyn bazodanowych (ang. database machines), jednak działania te nie miały większego odzwierciedlenia w ofertach rynkowych. Wtedy to powstał funkcyjny model danych, ale oprócz specjalnych zastosowań nie miał szerszych zastosowań. Lata dziewięćdziesiąte XX wieku, to praca w kierunku obiektowych baz danych. Korzystano z nich tam, gdzie konieczna była obsługa bardziej skomplikowanych danych, a bazy relacyjne nie mogły sobie z nimi poradzić. Przykładem były: przestrzenne bazy danych (ang. spatial databases), dane inŝynieryjne i dane multimedialne. W tych latach rozprzestrzeniły się baz danych Open Source, takie jak PostgreSQL i MySQL. Pierwsze lata XXI wieku są okresem duŝego zainteresowania bazami danych XML. W tym czasie, podobnie jak to było w przypadku obiektowych baz danych, powstało sporo nowych firm-producentów, ale kluczowe ich elementy są wbudowywane takŝe w istniejące relacyjne bazy danych. Celem baz danych XML jest usunięcie tradycyjnego podziału na dokumenty i dane, pozwalając na trzymanie wszystkich zasobów informacyjnych organizacji w jednym miejscu Rodzaje baz danych Bazy danych moŝna podzielić według struktur danych, których uŝywają: 1. Bazy proste: a. Bazy kartotekowe b. Hierarchiczne bazy danych c. Sieciowe bazy danych 2. Bazy złoŝone: 1. Bazy relacyjne 2. Bazy obiektowe 3. Bazy relacyjno-obiektowe 4. Strumieniowe bazy danych 5. Temporalne bazy danych 1. Bazy proste a. Bazy kartotekowe W bazach kartotekowych kaŝda tablica danych jest samodzielnym dokumentem i nie moŝe współpracować z innymi tablicami. Z baz tego typu korzystają liczne programy typu: ksiąŝka telefoniczna, ksiąŝka kucharska, spisy ksiąŝek, kaset i inne. Wspólną cechą tych baz jest ich zastosowanie w jednym, wybranym celu. b. Hierarchiczne bazy danych Elektroniczna baza danych, która do tej pory jeszcze uŝywana w duŝych magazynach. Powstała na początku lat sześćdziesiątych, oparta o strukturę drzewiastą o wielu gałęziach. Wszystkie elementy danych w bazie hierarchicznej są zorganizowane w logiczny sposób, to znaczy kaŝda wartość obiektu danych jest logicznie powiązaną z jedną lub kilkoma wartościami innego obiektu danych. Zalety takiej bazy to: przede łatwość wdroŝenia, prosta struktura, oraz bardzo krótki czas dostępu (o ile baza danych jest poprawnie napisana oraz poprawnie są stworzone relacje). Wada pozwala na tworzenie jedynie relacji jeden-do-jeden i jednen-do-wiele lub wiele-do-jeden. 17

18 Przykładem jest baza IBM IMS (ang. Information Management System). c. Sieciowe bazy danych Zmodyfikowana wersja modelu hierarchicznego, stworzona głównie w celu rozwiązania problemów związanych z bazami danych opartych właśnie o model hierarchiczny. Elementy danych w tym modelu są zorganizowane w strukturę drzewiastą podobnie jak w przypadku modelu hierarchicznego. Jednak model sieciowy pozwala na definiowanie relacji wiele-wiele w postaci struktury drzewiastej bez powtarzania poszczególnych wartości w ramach obiektu danych. Zaletą jest szybkość, z jaką moŝna odczytać dane, oraz większe moŝliwości bazy. 2. Bazy złoŝone a. Bazy relacyjne W bazach relacyjnych wiele tablic danych moŝe współpracować ze sobą są między sobą powiązane. Więcej informacji o bazach relacyjnych znajduje się w kolejnym rozdziale. b. Bazy obiektowe W bazach obiektowych dane przechowywane są w strukturach obiektowych (zdefiniowanych jako klasy). Obecnie prace w kierunku tego typu baz nie są prowadzone prawie w ogóle. c. Bazy relacyjno-obiektowe Bazy relacyjno-obiektowe pozwalają na manipulację danych jako zestawem obiektów. Jako mechanizm do zapisu danych uŝywana jest baza relacyjna. d. Strumieniowe bazy danych Strumieniowa baza danych to baza danych, w której dane są przedstawione w postaci zbioru strumieni danych. System zarządzania taką bazą nazywany jest strumieniowym systemem zarządzania danymi. Większość strumieniowych baz danych w chwili obecnej znajduje się w fazach prototypowych i nie powstały dotychczas rozwiązania komercyjne. e. Temporalna baza danych Temporalna baza danych jest odmianą bazy relacyjnej, w której kaŝdy rekord posiada stempel czasowy, określający czas, w jakim wartość jest prawdziwa. Posiada takŝe operatory algebry relacyjnej, które pozwalają operować na takich danych. 3.2 Modele danych uŝywane w systemach baz danych Model danych (a w odniesieniu do konkretnej realizacji mówi się często o architekturze systemu baz danych) moŝna rozumieć jako zbiór ogólnych zasad posługiwania się danymi. Zbiór ten obejmuje trzy główne części: 1. Definicja danych: zbiór reguł określających logiczną strukturę danych, w odróŝnieniu od niŝszego poziomu organizacji zapisu stosowanego wewnętrznie przez jądro bazy danych 2. Operowanie danymi: zbiór reguł dotyczących procesu dostępu do danych i ich modyfikacji 3. Integralność danych: zbiór reguł określających, które stany bazy danych są poprawne (jakie operacje prowadzące do modyfikacji danych są dozwolone). RozróŜnia się trzy główne typy (lub generacje) modeli danych: 18

19 1. Proste modele danych dane zorganizowane są w strukturę rekordów zgrupowanych w plikach. Głównymi dostępnymi operacjami są operacje na wierszach (ewentualnie na ich poszczególnych polach). 2. Klasyczne modele danych naleŝą do nich modele hierarchiczne, sieciowe i relacyjne. Modele relacyjne stanowią najbardziej popularną obecnie podstawę architektur systemów baz danych. 3. Semantyczne (znaczeniowe) modele danych. Klasyczne modele danych nie dostarczają łatwego sposobu odczytania informacji o semantyce danych, stąd podejmuje się próby stworzenia innych modeli, uzupełniających ten brak. Przykładem częściowej realizacji tego programu są obiektowe modele danych Model relacyjny Model ten opiera sie na pojęciu matematycznej relacji, która przypomina tabele wartości właśnie relacje pełnia role podstawowych elementów składających się na konstruowane struktury. Model relacyjny bazuje równieŝ na teorii zbiorów, logice pierwszego rzędu i rachunku predykatów. Relacyjny model danych zawdzięcza swoje powstanie E. F. Coddowi, którego opublikowana w roku 1970 praca połoŝyła fundament pod ten najbardziej popularny ze współczesnych modeli danych. Od roku 1968 do 1988 E.F. Codd opublikował ponad 30 prac na temat relacyjnego modelu danych, on sam prace wydane przed rokiem 1979 traktuje jako dokumentacje pierwszej wersji relacyjnego modelu danych. W roku 1979, na konferencji Australian Computer Society w miejscowości Horbert w Tasmanii E. F. Codd przedstawił prace, w której sformułował rozszerzona wersje relacyjnego modelu danych, nazwał ja RM/T. W roku 1990 E. F. Codd opublikował ksiąŝkę, w której opisał wersje drugą relacyjnego modelu danych, deklarując przy tym, ze większość producentów systemów zarządzania relacyjnymi bazami danych nie rozumie implikacji zawartych w wersji pierwszej i wersji RM/T relacyjnego modelu danych. Relacyjny model danych wyróŝnia sie spośród innych modeli jednolitymi i solidnymi podstawami teoretycznymi. E. F. Codd opracował ścisłe metody posługiwania sie danymi wykorzystując do tego matematykę, w szczególności teorie zbiorów. Dane w modelu relacyjnym są reprezentowane jako zbiór krotek, które w znormalizowanych bazach danych są unikatowe i ich kolejność nie gra roli. Dostęp do nich jest realizowany za pomocą algebry relacji czyli dostęp do danych definiujemy poprzez operatory relacyjne takie jak: rzutowanie, selekcja, złączenie, suma, róŝnica, produkt kartezjański. Ograniczenie nadmiarowości danych dokonuje się w procesie przejścia do kolejnych postaci normalnych. Zbiory danych powiązane są logicznie za pomocą encji. W ten sposób uniezaleŝnia się widziany przez uŝytkownika obraz bazy danych od jej postaci fizycznej. Opis relacyjnego modelu danych moŝna podzielić na trzy części: 1. Struktury danych 2. Języki manipulowania danymi 3. Integralność danych. 1. Struktury danych Model relacyjny oparty jest na tylko jednej podstawowej strukturze danych relacji. Pojęcie relacji moŝna uwaŝać za pewną abstrakcję intuicyjnego pojęcia tabeli, 19

20 zbudowanej z wierszy i kolumn, w której na przecięciu kaŝdej kolumny z kaŝdym wierszem występuje określona wartość. Baza danych jest zbiorem relacji, o następujących własnościach: KaŜda relacja w bazie danych jest jednoznacznie określona przez swoją nazwę KaŜda kolumna w relacji ma jednoznaczną nazwę (w ramach tej relacji) Kolumny relacji tworzą zbiór nieuporządkowany (kolumny nazywane bywają równieŝ atrybutami) Wszystkie wartości w danej kolumnie muszą być tego samego typu (zbiór moŝliwych wartości elementów danej kolumny nazywany bywa teŝ jej dziedziną) Wiersze relacji tworzą nieuporządkowany zbiór; w szczególności, nie ma powtarzających się wierszy. Wiersze relacji nazywa się teŝ encjami. KaŜde pole (przecięcie wiersza z kolumną) zawiera wartość atomową z dziedziny określonej przez kolumnę. Brakowi wartości odpowiada wartość specjalna NULL, zgodna z kaŝdym typem kolumny (chyba, Ŝe została jawnie wykluczona przez definicję typu kolumny). KaŜda relacja zawiera klucz główny kolumnę (lub kolumny), której wartości jednoznacznie identyfikują wiersz (a więc w szczególności nie powtarzają się). Wartością klucza głównego nie moŝe być NULL. Do wiązania ze sobą danych przechowywanych w róŝnych tabelach uŝywa się kluczy obcych. Klucz obcy to kolumna lub grupa kolumn tabeli, o wartościach z tej samej dziedziny, co klucz główny tabeli z nią powiązanej. 2. Języki manipulowania danymi Relacyjny model danych określa dwa języki manipulowania danymi: algebrę relacyjną i rachunek relacyjny. Algebra relacyjna operuje na relacjach, jest językiem proceduralnym i algorytmicznym dla uzyskania specyficznej informacji moŝliwe jest określenie ciągu operacji, które przekazując sobie kolejno wynik swojego działania relacje, jako argument kolejnej operacji, doprowadzają do poŝądanego wyniku końcowego. Rachunek relacyjny jest językiem deklaracyjnym, nieproceduralnym określa on, co ma zostać wyszukane a nie sposób, w jaki ma to zostać zrobione. E. F. Codd proponując relacyjny model danych najwięcej uwagi poświęcił wyszukiwaniu danych, które jest jednym z pięciu aspektów operowania danymi pozostałe cztery to porównywanie, wstawianie, usuwanie i poprawianie danych. Dla celów porównywania danych E. F. Codd zaproponował dodatkowy zbiór operacji algebry relacyjnej. Operacje te nazywane są niekiedy operacjami teta. Wspólne dla obu języków są operacje wstawiania, usuwania i poprawiania danych. 1. Operacje algebry relacyjnej Selekcja jest operacją jednoargumentową, określoną przez warunek dotyczący wartości kolumn danej relacji. Wynikiem jej jest relacja zawierające te wszystkie encje (wiersze) wyjściowej relacji, których atrybuty spełniają dany warunek. Rzut (lub inaczej projekcja) operacja jednoargumentowa określona przez podzbiór zbioru kolumn danej relacji, dająca w wyniku tabelę składającą się z tych kolumn wyjściowej relacji. 20

21 Iloczyn kartezjański argumentami są dwie relacje, wynikiem relacja, której wiersze są zbudowane ze wszystkich par wierszy relacji wyjściowych. Równozłączenie argumentami są dwie relacje, posiadające kolumny o tych samych dziedzinach np. klucz główny jednej z nich i klucz obcy drugiej. Wynikiem jest tabela otrzymana z iloczynu kartezjańskiego relacji wyjściowych poprzez selekcję za pomocą warunku równości tych wspólnych atrybutów. Złączenie naturalne powstaje z równozłączenia dwóch tabel przez rzutowanie usuwające powtarzające się kolumny złączenia. W rzeczywistości jest to operacja bardziej naturalna niŝ równozłączenie. Złączenia zewnętrzne tworzone są podobnie jak złączenie naturalne, lecz z pozostawieniem w tabeli wynikowej takŝe wierszy, dla których nie zachodzi równość atrybutów złączenia: w przypadku złączenia lewostronnego złączenie naturalne uzupełnia się o wiersze z pierwszego argumentu nie posiadające odpowiednika (wierszu o równym atrybucie złączenia) w drugim argumencie; brakujące atrybuty przyjmują wartość NULL. W złączeniu prawostronnym robi się to samo, ale względem drugiego argumentu. Wreszcie złączenie obustronne obejmuje obydwie tabele wyjściowe tą samą operacją. Suma jest operatorem działającym na dwóch zgodnych relacjach (o tych samych kolumnach), produkującym relację, której wiersze są sumą teoriomnogościową wierszy z relacji wyjściowych. Przecięcie wymaga dwóch zgodnych tabel, wynikiem jest tabela zawierająca wiersze wspólne dla obu argumentów. RóŜnica jest określona dla dwóch zgodnych relacji i odpowiada dokładnie róŝnicy teoriomnogościowej zbiorów wierszy tabel wyjściowych. 2. Operacje rachunku relacyjnego Wstawianie danych relacyjny model danych zapewnia moŝliwość wstawiania danych do relacji. Operacja wstawiania danych wstawia do relacji krotkę. Usuwanie danych przy pomocy tej operacji moŝna usunąć z relacji jedna lub wiele określonych warunkiem krotek. Poprawianie danych operacja poprawiania danych (zwana teŝ czasem operacją aktualizacji danych) pozwala zmienić wartość jednego lub wielu atrybutów dla określonych warunkiem krotek. Istnieją dwa równowaŝne rodzaje rachunku relacyjnego: rachunek relacyjny na krotkach i rachunek relacyjny na dziedzinach. Rachunek relacyjny na krotkach jest podstawą języka SQL (ang. Structured Query Language strukturalny język zapytań), natomiast rachunek relacyjny na dziedzinach podstawa języka QBE2 (ang. Query By Example zapytanie przez przykład). 3. Integralność Integralność to ograniczenie nakładane na bazę danych przez model relacyjny. Dwie podstawowe reguły integralności to: 21

22 a. Integralność encji kaŝda tabela musi posiadać klucz główny, a wartości klucza głównego muszą być w ramach tabeli unikalne i róŝne od NULL. W szczególności, zapobiega to wystąpieniu w tabeli powtórzeń wierszy. b. Integralność referencyjna kaŝda wartość klucza obcego moŝe być albo równa jakiejś wartości klucza głównego występującej w tabeli powiązanej, lub (ewentualnie) NULL. Pociąga to za sobą konieczność określenia reguły postępowania w wypadku usuwania wiersza z tabeli powiązanej, co mogłoby uniewaŝnić niektóre wartości kluczy obcych w tabelach do niej się odnoszących. W grę wchodzą trzy postacie takiej reguły: Zmiany ograniczone (ang. restricted) usunięcie wiersza jest zabronione, dopóki nie zostaną usunięte lub odpowiednio zmodyfikowane wiersze z innych tabel, których wartości kluczy obcych stałyby się wskutek tej operacji niewaŝne; Zmiany kaskadowe (ang. cascades) usunięcie wiersza powoduje automatyczne usunięcie z innych tabel wszystkich wierszy, dla których wartości kluczy obcych stały się niewaŝne; Zmiany powodujące ustawienie wartości klucza obcego na NULL (ang. nullifies) usunięcie lub zmiana wartości klucza głównego krotki powoduje ustawienie wartości wszystkich kluczy obcych odnoszących sie do usuniętej wartości klucza głównego na NULL. 3.3 Relacyjne bazy danych Na modelu relacyjnym oparta jest relacyjna baza danych (RDBMS ang. Relational Database Management Systems) baza danych, w której dane są przedstawione w postaci relacyjnej. Relacja reprezentowana jest przez tablicę (tablica = relacja, od tego pochodzi nazwa) a tablice są zbiorem rekordów o identycznej strukturze i wewnętrznie powiązanych za pomocą związków zachodzących pomiędzy danymi. Powoduje to ułatwienie zarządzania bazą danych w stosunku do tradycyjnego podejścia, gdzie dane są przechowywane w postaci strumienia. Takie podejście ułatwia wprowadzania zmian, zmniejszenie moŝliwość pomyłek, ale dzieje się to kosztem wydajności. Bazy relacyjne posiadają wewnętrzne języki programowania, wykorzystujące zwykle język SQL do operowania na danych, za pomocą których tworzone są zaawansowane funkcje obsługi danych. Relacyjne bazy danych (jak równieŝ przeznaczony dla nich standard SQL) oparte są na kilku zasadach: 1. Wszystkie wartości danych oparte są na prostych typach danych. 2. Wszystkie dane w bazie relacyjnej przedstawiane są w formie dwuwymiarowych tabel (relacji). KaŜda tabela zawiera zero lub więcej wierszy (krotek) i jedną lub więcej kolumn (atrybutów). Na kaŝdy wiersz składają się jednakowo ułoŝone kolumny wypełnione wartościami, które z kolei w kaŝdym wierszu mogą być inne. 3. Po wprowadzeniu danych do bazy, moŝliwe jest porównywanie wartości z róŝnych kolumn, zazwyczaj równieŝ z róŝnych tabel oraz scalanie wierszy, gdy pochodzące z nich wartości są zgodne. UmoŜliwia to wiązanie danych i wykonywanie stosunkowo złoŝonych operacji w granicach całej bazy danych. 4. Wszystkie operacje wykonywane są w oparciu o algebrę relacji, bez względu na połoŝenie wiersza tabeli. Wiersze w relacyjnej bazie danych przechowywane są przechowywane nieuporządkowane sposób zapisu nie musi odzwierciedlać ani kolejności ich wprowadzania, ani kolejności ich przechowywania. 5. Z braku moŝliwości identyfikacji wiersza przez jego pozycję pojawia się potrzeba obecności jednej lub więcej kolumn niepowtarzalnych w granicach całej tabeli, 22

23 pozwalających odnaleźć konkretny wiersz. Kolumny te określa się jako klucz podstawowy (ang. primary key) tabeli. 3.4 Systemy baz danych uŝywane w eksperymencie Pi of the Sky Wymagania dotyczące bazy uŝywanej w eksperymencie Prezentowane wymagania dotyczą przede wszystkim wymagań dotyczących katalogu gwiazd, który jest największą częścią danych przechowywanych w ramach eksperymentu. Oprócz pomiarów gwiazd w eksperymencie zbierane są inne informacje, jak fotografie nieba, wykryte zdarzenia, dane konfiguracyjne, jednak ich wielkość jest na tyle niewielka, Ŝe kaŝdy system bazodanowy spełniałby potrzeby na ich przechowywanie i przetwarzanie. Główne wymagania stawiane sposobowi przechowywania danych to: Niezawodność dane powinny być dostępne dla uŝytkowników w kaŝdym momencie Skalowalność na obecną chwilę zebranych danych jest juŝ ok. 2TB i ilość ta w przyszłości będzie stale wzrastać Stabilność błędy w działaniu oprogramowania nie mogą dopuścić do utraty zgromadzonych danych Wydajność dostęp do danych musi odbywać się w rozsądnym czasie Zarządzanie musi być zapewniony łatwy dostęp do danych Bezpieczeństwo dostęp do systemu przez osoby z zespołu Pi of the Sky, ale takŝe przez zewnętrznych uŝytkowników Koszt w związku z tym, Ŝe jest to eksperyment non-profit fundusze są mocno ograniczone System PostgreSQL przegląd moŝliwości PostgreSQL jest bardzo zaawansowanym i jednym z najpopularniejszych wolnodostępnych (typu open source) systemów zarządzania relacyjnymi bazami danych. PostgreSQL nie jest kontrolowany przez pojedynczą firmę, tylko polega na globalnej społeczności osób i firm wspomagających jego tworzenie. PostgreSQL zalicza się do baz typu RDBMS z rozszerzeniami obiektowymi. Cechy PostgreSQL to między innymi: Osadzane języki proceduralne wykonywane przez bazę danych (plperl, pl/perl, plpgsql, plpython, pltcl, pl/tcl) MoŜliwość tworzenia funkcji w PostgreSQL w języku C, kompilowanych do bibliotek dynamicznych Sterowniki dostępu do bazy z języków C, C++, python, perl, czy Java (poprzez JDBC), ODBC Wysoce zaawansowana implementacja standardu SQL, obejmująca standard SQL/92 Obsługa obiektów BLOB (Binary Large OBjects) duŝych obiektów binarnych, takich jak pliki graficzne, itp. Licencja BSD, która umoŝliwia zamykanie kodu PostgreSQL przy dokonywaniu modyfikacji, co jest istotne w rozwiązaniach biznesowych 23

24 Historia powstania systemu Prace nad rozmowejm PostgreSQL zaczęły się w 1973 roku. W roku tym dr Michael Stonebraker wraz z Eugene Wong rozpoczęli badania nad relacyjnymi systemami baz danych. Efektem tych badań było rozpoczęcie projektu Ingres na Uniwersytecie Kalifornijskim w Berkeley w 1977 roku. Projekt prowadzony był pod kierunkiem dr Michaela Stonebrakera, który w 1982 roku opuścił uczelnię, zakładając firmę, która zajęła się komercyjną wersją systemu Ingres. Jednak wkrótce, w 1984 roku wrócił na uczelnię. W 1985 roku rozpoczęto pod kierunkiem prof. Michaela Stonebrakera prace badawcze nad projektem obiektowo-relacyjnej bazy danych Postgres (post-ingres). Postgres został wyposaŝony w zaawansowany język zapytań POSTQUEL. Następnie w 1987 roku zaimplementowano do Postgresa reguły, procedury, typy i elementy obiektowe. Projekt ten był sponsorowany przez Defense Advanced Research Projects Agency (DARPA), Army Research Office (ARO), National Science Foundation (NSF) i ESL, Inc. Później projekt skomercjalizowano nadając mu nazwę Illustra, który ostatecznie wykupiła firma Informix. Firma Informix uŝyła system Illustra w swoim produkcie Universal Server. W przeciwieństwie do projektu Ingres, projekt Postgres był nadal udoskonalany na uniwersytecie. Wersję oznaczoną numerem 1 opublikowano w czerwcu 1989 roku. Następnie w 1990 roku została opublikowana wersja 2, w której przepisano systemem reguł. Natomiast w 1991 roku ukazała się wersja 3 zawierająca m.in. przepisany na nowo systemem reguł i poprawiony silnik zapytań. Ostatnią wersją projektu Postgres była wersja 4.2, która nadal bazowała na języku zapytań POSTQUEL. Dwaj absolwenci, członkowie zespołu Stonebraker'a, Andrew Yu i Jolly Chen w 1994 roku dodali interpreter języka SQL, zastępując język zapytań POSTQUEL. Projekt ten udostępniono na licencji BSD w maju 1995 roku, jako Postgres95. Dalszą pracą nad projektem podjęła w 1996 roku społeczność Open Source, zmieniając nazwę projektu na PostgreSQL i tworząc organizację PostgreSQL Global Development Group do koordynacji rozwoju projektu. Zdecydowano się, Ŝe nowa wersja będzie oznaczona numerem 6.0, jako następca Postgres95, którego moŝna oznaczyć jako wersję 5.0 systemu macierzystego Postgres. W 2001 roku przez Command Prompt, Inc. zostaje wydany Mammoth PostgreSQL, najstarsza istniejąca komercyjna dystrybucja PostgreSQL. Firma ta aktywnie wspiera do dnia dzisiejszego społeczność PostgreSQL przez sponsorowanie programistów i projektów dotyczących m.in. PL/Perl, PL/php oraz hostuje dla projektu PostgreSQL Build Farm System IBM DB2 przegląd moŝliwości IBM DB2 wchodzi w skład rodziny relacyjnych systemów zarządzania bazami danych (RDBMS) stworzonych przez IBM w ramach linii produktów Information Management Software. Produkty z tej linii są tworzone na wszelkie rodzaje maszyn, począwszy od małych systemów w urządzeniach przenośnych, a skończywszy na systemach stworzonych dla potęŝnych maszyn typu mainframe. Do głównych cech systemu DB2 moŝna zaliczyć: Nowatorskie funkcje samo zarządzania i autodostrajania, pozwalające znacznie ograniczyć czas i koszty związane z zarządzaniem serwerami baz danych. Jedna z najlepszych obsługa stowarzyszonych usług WWW (Federated Web Services) i języka XML. Zgodność z otwartymi standardami i moŝliwość przenoszenia między platformami uniwersalnymi. 24

25 Zaawansowana obsługa inteligentnej analizy danych dzięki funkcji wielowymiarowego grupowania danych (Multi-Dimensional Clustering MDC). Moduł programistyczny Development Center, wyposaŝony w narzędzia pozwalające na tworzenie procedur składowanych w środowiskach Java i Microsoft. MoŜliwość integracji z innym oprogramowaniem IBM UmoŜliwienie korzystania z dowolnych informacji za pomocą dowolnej aplikacji, z kaŝdego miejsca i w kaŝdej chwili Historia powstania systemu W 1970 Edgar Frank Codd pracując dla IBM, opublikował A Relational Model of Data for Large Shared Data Banks pracę na temat relacyjnego modelu organizacji danych. Model relacyjny i pierwowzór języka SQL (wtedy określanego jako Alfa) po raz pierwszy zostały zaimplementowany przez IBM w projekcie System R (System Rational), będącym przodkiem DB2, prowadzonym w latach w San José Laboratory w Kalifornii. Od tego czasu IBM stworzył całą rodzinę oprogramowania relacyjnych systemów zarządzania bazą danych (RDBMS). Początkowo oprogramowanie było przeznaczone tylko na platformy typu mainframe jak Virtual Machine (VM) czy Virtual Storage Extended (VSE). Nazwa DB2 została uŝyta po raz pierwszy dla RDBMS w 1983, kiedy IBM udostępnił pierwszą wersję na platformę Multiple Virtual Storage (MVS). Nazwa DB2 (skrót od Database 2) symbolizuje bazę danych drugiej generacji jako znak odejścia od podejścia hierarchicznego. Aktualnie DB2 jest rozwijane zarówno na platformach typu mainframe, jak i platformach systemów otwartych. DB2 na OS/2 Extended Edition wprowadzony w 1987 był pierwszym systemem przeznaczonym na platformę otwartą. W 1997 IBM ogłosił wprowadzenie IBM DB2 v5. Od tej wersji DB2 była zdolna przechowywać kaŝdy rodzaj danych elektronicznych takich jak: audio, wideo czy dokumenty tekstowe. Była teŝ pierwszą wersją zoptymalizowaną dla Internetu. Wspierała większość platform takich: OS/2, Windows, AIX, HP-UX i Solaris. Od wersji piątej DB2 działała na róŝnych konfiguracjach sprzętowych: platformach jednoprocesorowych, symetrycznych platformach wieloprocesorowych (SMP Symmetric MultiProcessing Systems), systemach masywnego przetwarzania równoległego (MPP Massively Parallel Processors) i klastrach. IBM dodał do nazwy bazy danych termin uniwersalna dla podkreślenia jej nowych cech i elastyczności. Od wersji piątej kolejne dystrybucje DB2 przyjmowały nazwę IBM DB2 UDB. Obecnie w odniesieniu do DB2 uŝywana jest nazwa IBM DB2 LUW (Linux, Unix, Windows). W DB2 v9 IBM wykorzystał doświadczenie z okresu modelu hierarchicznego wprowadzając silnik hybrydowy hierarchiczno relacyjny wspomagający obsługę dokumentów XML. Pod koniec 2007 została wprowadzona na rynek najnowsza edycja IBM DB2 v Porównanie moŝliwości PostgreSQL i IBM DB2 Obsługiwane systemy operacyjne: Windows Mac OS X Linux BSD UNIX AmigaOS z/os IBM DB2 Tak Nie Tak Nie Tak Nie Tak PostgreSQL Tak Tak Tak Tak Tak Tak Nie Tabela 1 obsługiwane systemy operacyjne 25

26 Podstawowe cechy: ACID Integralność referencyjna Transakcje Wsparcie Unicode Interfejs IBM DB2 Tak Tak Tak Tak GUI & SQL PostgreSQL Tak Tak Tak Tak SQL Tabela 2 podstawowe cechy Limity: o Rozmiary przechowywania danych Maks. rozmiar bazy Maks. rozmiar tabeli Maks. rozmiar wiersza Maks. ilość kolumn w wierszu IBM DB2 512 TB 512 TB 32,677 B 1012 PostgreSQL Nieograniczona 32 TB 1.6 TB Tabela 3 rozmiary przechowywania danych o Rozmiary typów danych : Maks. wielkość obiektów Blob/Clob Maks. wielkość typu CHAR Maks. Wielkość typu NUMBER IBM DB2 2 GB 32 KB 64 bity PostgreSQL 1 GB 1 GB Nieograniczona Tabela 4 rozmiary typów danych Tabele i widoki: Tabele tymczasowe Zmaterializowane widoki IBM DB2 Tak Tak PostgreSQL Tak Nie Tabela 5 tabele i widoki Obsługiwane typy indeksów: R-/R+ tree Hash Expression Partial Reverse Bitmap GiST GIN IBM DB2 Nie? Tak Nie Tak Tak Nie Nie PostgreSQL Tak Tak Tak Tak Tak Tak Tak Tak Tabela 6 obsługiwane typy indeksów Obsługiwane operatory: Suma Przecięcie RóŜnica Złączenie wew. Złączenie zew. Podzapytanie Obiekty Blob/Clob IBM DB2 Tak Tak Tak Tak Tak Tak Tak PostgreSQL Tak Tak Tak Tak Tak Tak Tak Tabela 7 obsługiwane operatory 26

27 Natywne obiekty: Kursory Wyzwalacze Funkcje (wew.) Procedury (wew.) Procedury składowane (zew.) IBM DB2 Tak Tak Tak Tak Tak PostgreSQL Tak Tak Tak Tak Tak Tabela 8 natywne obiekty Partycjonowanie: Zakresowe Przez hashowanie ZłoŜone (zakresowe + przez hashowanie) IBM DB2 Tak Tak Tak PostgreSQL Nie Nie Nie Tabela 9 partycjonowanie 3.5 Dlaczego IBM DB2? System bazy danych IBM DB2 oparty jest na architekturze shared-nothing (niewspółdzielonej), w przeciwieństwie do innych systemów o architekturach shared-disk (współdzielenie dysków) lub shared-memory (współdzielenie pamięci). Główną zaletą architektury niewspółdzielonej jest zdolność do rozpraszania wszystkich danych na kilka fizycznych serwerów niemal w liniowym czasie. Architektura ta jest najlepszym sposobem na równomierne rozłoŝenie obciąŝenia na wszystkie serwery z wykorzystaniem mocy do przetwarzania zapytań kaŝdego z nich (dysków, pamięci, procesorów). Rysunek 10 - środowisko niewspółdzielone 27

28 Partycjonowanie bazy danych poprawia wydajność zapytań, zapewnia skalowalność systemu i ułatwia zarządzanie. System IBM DB2 spełnia wymagania dotyczące: Zdolności do obsługi bazy przez wielu uŝytkowników i aplikacji jednocześnie Skalowalności, tj. zdolności do utrzymywania charakterystyki operacyjnej na tym samym poziomie w miarę ciągłego rozwoju systemu W docelowej wersji eksperymentu danych będzie coraz więcej, więc system PostgreSQL mimo wielu swoich zalet nie sprawdziłby się z powodu braku funkcjonalności rozproszenia bazy danych oraz problemów z obsługą tak wielkich ilości danych dane te musiałyby być obsługiwane przez jeden fizyczny serwer, który w niedługim czasie nie byłby w stanie przetworzyć tak ogromnych ilości danych ze względu na zbyt małą moc obliczeniową. Rozwiązaniem byłoby podzielenie bazy na kilka serwerów i obsługa kaŝdej z części oddzielnie, jednak z dłuŝszej perspektywy takie rozwiązanie byłoby bardzo kłopotliwe, poniewaŝ utrzymanie spójności między oddzielnymi bazami wymagałoby coraz większego wysiłku ze strony osób zajmujących się bazą. Funkcjonalności związane z moŝliwością rozproszenia bazy danych na kilka serwerów i tym samym obsługi coraz większej ilości danych przyczyniły się do tego, Ŝe eksperyment będzie w dalszej perspektywie rozwijany na systemie IBM DB2. 4 Baza danych w eksperymencie Pi of the Sky 4.1 Tabele wchodzące w skład bazy Pi of the Sky W skład bazy danych wchodzą następujące tabele (część tabel ma znaczenie marginalne, dlatego opisane zostały tylko najwaŝniejsze): Alert Astroobject Nazwa tabeli Dane słownikowe (t/n) N T 28 Dane zapisane w tabeli Przechowywane są powiadomienia o błyskach gamma i innych ciekawych zjawiskach na niebie wysłane przez sieć GCN Zapisane są dane o obiektach niebieskich (np. planet) wprowadzonych przez uŝytkowników poprzez stronę WWW lub programy liczące połoŝenia planet Cameras T Dane słownikowe opisujące szczegóły kamer Events N Gromadzone są wyniki algorytmów do wykrywania błysków działających on-line, tj. algorytmów działających na surowych danych pochodzących z kamer Event_desc N Zapisane są opisy interesujących wykrytych przypadków Field_def T Słownik z definicjami pól obserwowanych na niebie Zapisywane są informacje o zdjęciach wykonanych N Frame przez kamery Zapisywane są informacje dotyczące listy zdjęć, z N Frame_averaged których powstało zdjęcie uśrednione Przechowywane są dodatkowe szczegóły zdjęć N Frame_det wykonanych przez kamery

29 Grb N Zawarte są dane o błyskach wykrytych przez satelity Grblc N Zapisywane są dane dotyczące krzywych blasku błysków Hotpixel T Przechowywane są informacje o gorących pikselach (wadliwych) na kamerze CCD Interestingobjects N Zgromadzone są dane o interesujących obiektach zasługujących na późniejszą obserwację Lightcurve N Zapisane są dane dotyczące krzywych blasków najciekawszych przypadków wykrytych przez algorytm on-line Measurements N Przechowywane są szczegółowe informacje o wykonanych pomiarach jasności gwiazd Mountspeed N Zawarte są dane dotyczące prędkości montaŝu z zainstalowanymi kamerami w trakcie nocy Nightstat N Zgromadzone są opis poszczególnych nocy, w jakich były wykonywane obserwacje nieba, oraz dane dotyczące wykonanych w trakcie nocy analiz Obsfieldstat N Zapisane są statystyki obserwacji danego pola Pimancommand N Przechowywane są szczegóły poleceń wykonany ch przez system zarządzający teleskopem Sn N Zawarte są dane o supernowych, które zostały zaobserwowane przez inne teleskopy Stars N Zgromadzone są wszystkie dane o obiektach zaobserwowanych przez kamery Superstar N Zawarte są informacje o fizycznych gwiazdach, które są obserwowane przez aparaturę Flareevents N Gromadzone są wyniki algorytmów do wykrywania błysków działających off-line, tj. algorytmów działających, które zostały wcześniej zapisane do bazy danych) Tabela 10 - tabele w bazie danych 4.2 Katalog gwiazd Schemat katalogu gwiazd W modelu bazy zastosowane zostały więzy integralności w postaci kluczy, które jednoznacznie identyfikują wiersze w tabelach. Ze względów wydajnościowych w modelu usunięto więzy integralności referencyjnej (klucze obce) proces ładowania danych przy utworzonych więzach jest znacznie wolniejszy, poniewaŝ przy ładowaniu kaŝdego wiersza do tabeli ich poprawność musi zostać sprawdzona. Klucze takie jednak zostały utworzone na etapie projektowania systemu i chociaŝ tabele nie są powiązane w bazie (brak klauzuli CONSTRAINT FOREIGN KEY dla tabel) to model jest logicznie powiązany. NajwaŜniejszą częścią bazy danych w eksperymencie są tabele, w których przetrzymywane są informacje o gwiazdach i ich pomiarach. PoniŜej przedstawiony jest schemat logiczny katalogu gwiazd. 29

30 Rysunek 11 - schemat logiczny katalogu gwiazd (źródło 30

31 4.2.2 Tabele katalogu gwiazd W tabelach wchodzących w skład katalogu gwiazd znajdują się następujące dane : Tabele FRAME i FRAME_DET zawierają informacje o kaŝdym zdjęciu zapisanym w systemie Tabela EVENTS przechowuje informacje o wszystkich interesujących zdarzeniach wykrytych przez algorytm on-line Tabela STARS zawiera wszystkie dane o obiektach zaobserwowanych przez kamery. W związku z tym, Ŝe gwiazda moŝe być obserwowana w jednym momencie przez więcej niŝ jedną kamerę moŝe się pojawić kilka wpisów reprezentujących tą samą gwiazdę Tabela MEASUREMENTS gromadzi dane o wszystkich obserwacjach dotyczących gwiazd Tabela SUPERSTAR zawiera informacje o fizycznych gwiazdach, które są obserwowane przez aparaturę (niezaleŝnie od ilości kamer obserwujących gwiazdę w tym miejscu zapisana jest tylko jedna informacja na temat kaŝdej gwiazdy) Tabela OBS_FIELD_STAT przechowuje dane statystyczne o liczbie obrazów zgromadzonych dla poszczególnych pól Tabela FIELD_DEF zawiera definicje pól obserwowanych przez system Tabela STARS Nazwa kolumny Typ danych Opis id Integer Wewnętrzny identyfikator gwiazdy zapisanej w bazie ra Double Rektascensja (współrzędna astronomiczna) zapisana w godzinach dec Double Deklinacja (współrzędna astronomiczna) zapisana w stopniach magnitude Double Średnia jasność pomiarów gwiazdy (magnitudo) sigma_mag Double Średnia kwadratowa jasności gwiazdy (magnitudo) name Varchar Nazwa gwiazdy w formacie HHMM+DDMM.M. Nazwa składa się ze współrzędnych astronomicznych min_mag Double Minimalna jasność (magnitudo) gwiazdy max_mag Double Maksymalna jasność (magnitudo) gwiazdy no_measurements Double Ilość pomiarów jasności wykonanych dla gwiazdy mag_cat Double Wartość jasności (magnitudo) dla gwiazdy pochodząca z katalogu gwiazd ASAS magsum Double Suma wartości jasności gwiazdy mag2sum Double Suma wartości jasności gwiazdy podniesiona do kwadratu sigma_ra Double Średnia kwadratowa rektascensji sigma_dec Double Średnia kwadratowa deklinacji camid Integer Identyfikator kamery, która wykonała zdjęcie gwiazdy sstar_id Integer Identyfikator odnoszący się do fizycznej gwiazdy lub do gwiazdy z innej kamery field_id Integer Identyfikator pola, na podstawie którego gwiazda była obserwowana najczęściej sigma_field Double Średnia kwadratowa jasności na najlepszym polu sigma_night Double Minimalna średnia kwadratowa dla pojedynczej nocy tmp_value Real Pole uŝywane do przechowywania tymczasowych obliczeń 31

32 amp Real Pole Amp z tabeli zmiennych gwiazd ASAS period Real Okres (uŝywane w przypadku gwiazd zmiennych) hjd_t0 Real Jednostka czasu (HJD Heliocentric Julian Date) określająca kiedy pomiary zostały rozpoczęte cam2_sstar_id Integer Identyfikator gwizady zaobserwowanej na drugiej kamerze quality Int2 Informacja o wyniku działania aplikacji sprawdzającej jakość danych max_id_frm Integer Maksymalny numer identyfikatora zdjęcia, na którym została zaobserwowana gwiazda last_checked Integer Data nocy, w której ostatnio zostało przeprowadzone sprawdzenie jakości danych Tabela 11 - tabela STARS (źródło Tabela MEASUREMENTS Nazwa kolumny Typ danych Opis star Integer Identyfikator gwiazdy, której dotyczy pomiar time_hjd Double Jednostka czasu (HJD Heliocentric Julian Date) określająca kiedy został wykonany pomiar magnitude Double Jasność gwiazdy (magnitudo) error Double Błąd jasności gwiazdy id_frm Integer Identyfikator zdjęcia, na podstawie którego wykonane zostały pomiary jasności ra Double Rektascensja (współrzędna astronomiczna) zapisana w godzinach dec Double Deklinacja (współrzędna astronomiczna) zapisana w stopniach mag_piphoto Double Średnia jasność gwiazdy zaobserwowana przez aparaturę grade Text Stopień pomiaru ccdx Double Współrzędna X na chipie ccdy Double Współrzędna Y na chipie mag_ap0 Double Jasność zmierzona przez aparaturę 0 mag_ap1 Double Jasność zmierzona przez aparaturę 1 mag_ap2 Double Jasność zmierzona przez aparaturę 2 mag_ap3 Double Jasność zmierzona przez aparaturę 3 new_star Boolean Flaga określająca czy jest to pierwszy pomiar gwiazdy quality Int2 Informacja o wyniku działania aplikacji sprawdzającej jakość danych Tabela 12 - tabela MEASUREMENTS (źródło Tabela SUPERSTAR Nazwa kolumny Typ danych Opis id Serial Wewnętrzny identyfikator gwiazdy zapisanej w bazie name Text Nazwa gwiazdy ra Double Rektascensja (współrzędna astronomiczna) zapisana w godzinach dec Double Deklinacja (współrzędna astronomiczna) zapisana w stopniach v_mag Double Jasność Visual b_mag Double Jasność b (filtr niebieski) i_mag Double Jasność i-band period Double Okres (w dniach) star_type Integer Identyfikator słownika z typami gwiazd star_class Varchar(64) Klasa kształtu: EC/RRC/DSCT/ESD 32

33 other_id Varchar(64) Identyfikator w innym katalogu gwiazd other_class Varchar(64) Klasa w innym katalogu gwiazd gcvs_id Integer Identyfikator gwiazd w katalogu GCVS tycho_id Integer Identyfikator gwiazdy w katalogu TYCHO Tabela 13 - tabela SUPERSTAR (źródło Tabela INTERESTINGOBJECTS Nazwa kolumny Typ danych Opis io_id Serial Wewnętrzny identyfikator obiektu zapisanego w bazie io_name Varchar(64) Nazwa obiektu io_ra Double Rektascensja (współrzędna astronomiczna) zapisana w godzinach io_dec Double Deklinacja (współrzędna astronomiczna) zapisana w stopniach io_star_k2a Integer Identyfikator gwiazdy, która była obserwowana przez kamerę k2a io_star_k2b Integer Identyfikator gwiazdy, która była obserwowana przez kamerę k2b io_type Integer Typ interesującego obiektu io_vmag Double Jasność visual io_comment Varchar(128) Komentarz uŝytkownika dotyczący obiektu io_quality Integer Wartość jakości obiektu default 0 io_bmag Double Jasność b (filtr niebieski) io_star_type Varchar(8) Typ gwiazdy według katalogu SIMBAD io_no_measurements Integer Ilość wykonanych pomiarów jasności obiektu default 0 io_match_distance Double Odległość od gwiazdy pi do obiektu mierzona w arcsec Tabela 14 - tabela INTERESTINGOBJECTS (źródło Tabela FRAMES Nazwa kolumny Typ danych Opis id_frm Integer Wewnętrzny identyfikator zdjęcia zapisanego w bazie iframeno Integer Numer zdjęcia na dany dzień idaynight Integer Data nocy, w której było wykonane zdjęcie w formacie YYYYMMDD spathtofile Varchar(100) ŚcieŜka do pliku ze zdjęciem na dysku icamid Integer Identyfikator kamery wykonującej zdjęcie (2 = k2a, 3 = k2b) scamfilter Varchar(10) Filtr wykorzystywany przez uŝytkownika inaxis1 Integer Wielkość X zdjęcia inaxis2 Integer Wielkość Y zdjęcia sobject Varchar(20) Nazwa obserwowanego obiektu frotate Double Rotacja zdjęcia fra Double Rektascensja środka zdjęcia zapisana w godzinach fha Double Kąt godzinny środka zdjęcia zapisany w godzinach fdec Double Deklinacja środka zdjęcia zapisana w stopniach falt Double Wysokość środka zdjęcia zapisana w stopniach fzenith_d Double Odległość zenitalna środka zdjęcia zapisana w stopniach fazim Double Azymut środka zdjęcia zapisany w stopniach sdate_obs Date Data wykonania zdjęcia ttime_ut Integer Uniksowy znacznik czasu 33

34 sloctime Time Czas lokalny slocdate Date Data lokalna fjd Double Data w formacie juliańskim fhjd Double Data w formacie HJD Heliocentric Julian Date istarcount Integer Ilość gwiazd na zdjęciu ifitssize Integer Wielkość skompresowanego pliku ze zdjęciem bhas_jpg Boolean Flaga określająca, czy plik ze zdjęciem w formacie JPG dostępny jest poprzez stronę WWW posangle Double Astrometria kąt obrotu ast_ord Integer Astrometria kolejność transformacji wielomianowej asttime Integer Astrometria czas wykonania astrometrii ast_ver Varchar(16) Astrometria wersja algorytmu uŝywanego do wykonania astrometrii ast_err Double Astrometria błędy astrometrii ra2000 Double Astrometria rektascensja dec2000 Double Astrometria deklinacja par_x_? Double Astrometria parametr transformacji par_y_? Double Astrometria parametr transformacji flip Integer Astrometria określenie czy zdjęcie było odwrócone przed wykonaniem fotometrii errcode Integer Identyfikator kodu błędu : 0 OK., >0 pominięte w katalogowaniu matchedstars Integer Ilość gwiazd ze zdjęcia, które pasują do gwiazd zapisanych w katalogu shutter_mode Integer Tryb migawki : 1 - otwarta cały czas, 2 tryb standardowy fwhm_aver Double Średnia wartość FWHM w pliku ast avg Double Średnia wartość pikseli na zdjęciu rms Double Średnia kwadratowa wartości pikseli na zdjęciu star_fraction Double Stosunek ilości gwiazd na zdjęciu do ilość gwiazd w katalogu na tym polu cat_stars Integer Ilość gwiazd w katalogu na tym polu astrook Integer Flaga określająca czy proces astrometrii przebiegł pomyślnie avg_shape Double Średni kształt gwiazd na zdjęciu pixscale Double Skala pikseli na zdjęciu quality Int2 Flaga określająca jakość zdjęcia : JeŜeli >0 błędy ze zdjęciem: 1 wykryty ruch montaŝu 2 tymczasowy problem z systemem Tabela 15 - tabela FRAMES (źródło Tabela FIELD_DEF Nazwa kolumny Typ danych Opis fd_id Serial Wewnętrzny identyfikator pola zapisanego w bazie fd_name Varchar(16) Nazwa pola, np. : fd_ra Double Rektascensja zapisana w stopniach fd_dec Double Deklinacja zapisana w stopniach fd_ra_h Double Rektascensja zapisana w godzinach fd_original Boolean Flaga określająca czy jest to oryginalne pole pochodzące ze skryptu script init_fields.sql czy dodane później Tabela 16 - tabela FIELD_DEF (źródło 34

35 Tabela OBSFIELDSTAT Nazwa kolumny Typ danych Opis ofs_field Varchar(16) Identyfikator nazwy pola ze słownika z defincjami pól ofs_night Integer Noc ofs_ra Real Rektascensja ofs_dec Real Deklinacja ofs_night_count Integer Ilość obserwacji pola bieŝącej nocy ofs_count Integer Ilość wszystkich obserwacji pola do bieŝącej nocy Tabela 17 - tabela OBSFIELDSTAT (źródło Tabela EVENTS Nazwa kolumny Typ danych Opis fl_id Serial Wewnętrzny identyfikator zdarzenia zapisanego w bazie fl_star Integer Identyfikator gwiazdy, której dotyczy zdarzenie fl_night Integer Noc, w ciągu której zdarzenie zostało zarejestrowane fl_flare_mag Double Maksymalna jasność rozbłysku fl_mag_limit Double Limit jasności określający kiedy zdarzenie moŝna uznać za rozbłysk fl_good_count Integer Ilość pomiarów przekraczających limit jasności fl_peak_count Double Wysokość rozbłysku fl_quality Integer Flaga określająca jakoś zdarzenia fl_ccdx Double Współrzędna X zdarzenia fl_ccdy Double Współrzędna Y zdarzenia fl_min_time_hjd Double Początek okresu zdarzenia (w formacie HJD) wykrytego przez algorytm fl_max_time_hjd Double Koniec okresu zdarzenia (w formacie HJD) wykrytego przez algorytm fl_camid Integer Identyfikator kamery fl_cam2_sstar_id Integer Identyfikator gwiazdy na kamerze fl_comment Varchar(1024) Komentarz uŝytkownika fl_hjd Double Czas w formacie HJD piku rozbłysku fl_start_hjd Double Czas początku rozbłysku w formacie HJD fl_end_hjd Double Czas zakończenia rozbłysku w formacie HJD fl_xy_ok Integer Określa czy pozycja zmieniła się przez rozbłyskiem fl_type Integer Typ zdarzenia: 0 - rozbłysk, 1 - zdarzenie podobne do supernowej fl_near_star_count Integer Ilość otaczających gwiazd w promieniu 120 arcsec fl_min_mag Double Minimalna jasność podczas rozbłysku fl_max_mag Double Maksymalna jasność podczas rozbłysku fl_field_obs_count Integer Ilość obserwacji pola przed pojawieniem się rozbłysku fl_rej_reason Integer Flaga odrzucenia fl_id_frm Integer Identyfikator zdjęcia, na którym zostało wykryte zdarzenie fl_url Varchar(1024) Link URL do pliku w formacie fits/jpg fl_url2 Varchar(1024) Alternatywny link URL do pliku w formacie fits/jpg Tabela 18 - tabela EVENTS (źródło 35

36 4.3 Rozmiary bazy danych Ilości danych pochodzących z eksperymentu w obecnej fazie: Około 6 mln pomiarów na dobę Zdjęcia co 12 s., sumowane po 20 ~20000 gwiazd / zdjęcie ~10 godzin obserwacji / noc 2 kamery Ponad 1 mld pomiarów na rok ~200GB W bazie danych zgromadzone zostały informacje o milionach gwiazd i ich pomiarach: Baza z danymi z lat : 4.5 mln obiektów i 790 mln pomiarów (130 GB) Baza z danymi z lat : 10.8 mln obiektów i 1 miliard pomiarów (110 GB) Docelowo system będzie wyposaŝony w 32 kamery: 100 mln pomiarów na dobę 20 mld pomiarów na rok Nawet 20x więcej, jeśli obrabiane będą pojedyncze klatki Szacowana ilość danych ładowanych do tabel dziennie w docelowej fazie eksperymentu W docelowej fazie eksperymentu system będą obsługiwały 32 kamery, więc ilość danych, które będą musiały zostać przetworzone znacznie wyrośnie. Dane będą ładowane do tabel przechowujących katalog gwiazd w szacowanych wielkościach dziennie: Nazwa tabeli Event Event_desc Frame Frame_averaged Frame_det Lightcurve Measurements Obsfieldstat Stars Superstar Flareevents Szacowana ilość danych ładowanych dziennie Kilka tysięcy rekordów Max kilkaset rekordów ~ rekordów ~ kilka tysięcy ~ rekordów Kilkadziesiąt tysięcy rekordów ~ 16 x 4 GB ~kilkadziesiąt rekordów ~kilkadziesiąt tysięcy rekordów ~kilkadziesiąt tysięcy rekordów ~kilkadziesiąt tysięcy rekordów Tabela 19 - szacowana ilość danych ładowanych dziennie do systemu 36

37 5 Rozproszona baza danych Pobieranie danych z katalogu gwiazd w celu przeprowadzenia analiz danych za pomocą algorytmów off-line jest bardzo istotną sprawą w projekcie, w związku z tym konieczne jest opracowanie sposobu najbardziej wydajnego zapisu danych oraz ich najefektywniejszego pobierania i wyświetlenia końcowemu uŝytkownikowi. Prezentowanym podejściem jest uŝycie mocy kilku komputerów poprzez rozproszenie bazy danych na kilka serwerów. 5.1 Cechy rozproszonego systemu Do cech rozproszonego systemu moŝemy zaliczyć podział danych między partycjami oraz równoległość ich przetwarzania Podział danych między partycjami MoŜliwe są trzy schematy organizacji danych w bazie: Partycjonowanie bazy danych (database partitioning) Partycjonowania danych w tabelach: o Partycjonowanie zakresowe (table partitioning) o Organizacja pod względem wymiarów (multidimensional clustering) Partycjonowanie bazy danych (database partitioning) Przy partycjonowaniu (rozproszeniu/klastrowaniu) bazy danych system musi wiedzieć, na której partycji (database partition) zapisywać i odczytywać dane. Rozwiązaniem tego jest uŝycie mapy dystrybucji (distribution map) i klucza dystrybucji (distribution key). Mapa dystrybucji jest wewnętrznie generowaną tablicą zawierającą 4096 wpisów. Numery w tej tablicy cyklicznie wskazują na numer węzła w grupie partycji, gdzie są przechowywane dane. Mapa partycji w ten sposób zapewnia równomierne rozproszenie danych na wszystkich serwerach uczestniczących w partycjonowaniu. Sposobem wybierania numeru partycji jest uŝycie funkcji hashującej na kluczu dystrybucji. Kluczem dystrybucji jest kolumna/y w tabeli, której wartości są przekazywane do funkcji hashującej, w wyniku której zostanie wygenerowania wartość od 0 do 4095 z mapy dystrybucji wskazująca numer partycji. Dzięki rozproszeniu na kilka serwerów dane mogą być przetwarzane równolegle z uŝyciem mocy obliczeniowej kaŝdego z serwerów. 37

38 Rysunek 12 - rozpraszanie danych za pomocą map i klucza dystrybucyjnego Partycjonowanie danych w tabelach Partycjonowanie zakresowe (table partitioning) Dane w tabeli mogą zostać podzielone na partycje (data partitions), które przechowują zakresy danych. Dzięki takiemu podejściu moŝliwe jest wyeliminowanie przeszukiwania części danych, jeŝeli zapytanie się do nich nie odnosi i tym samym zwiększenie prędkości przetwarzania. Partycjonowanie danych odbywa się najczęściej po kolumnie, w której przechowywane są dane zakresowe, np. daty. Rysunek 13 - partycjonowanie tabeli po zakresie danych 38

39 Organizacja pod względem wymiarów (multidimensional clustering) Dane w tabelach zapisywane są fizycznie na dysku w blokach. Bloki te mogą być jednak rozrzucone po całym dysku, co opóźnia czas pobrania z nich danych, poniewaŝ dysk musi wykonać dodatkową pracę związaną z ich odnalezieniem. Fizyczny zapis na dysku danych w tabeli moŝe zostać specjalnie zorganizowany. SłuŜy do tego organizacja względem wymiarów, którymi są wybrane odpowiednie kolumny. Dzięki temu system zapisuje dane na dysku fizycznie w sąsiednich blokach, co skutkuje wzrostem szybkości ich pobrania Równoległość zapytań i operacji wejścia/wyjścia Główną zaletą partycjonowania bazy danych jest równoległość przetwarzania na wszystkich serwerach biorących udział w procesie tworzenia partycjonowanej bazy danych. Równoległość moŝemy rozpatrywać w dwóch aspektach: Równoległość zapytań: o Równoległość wewnętrzna (intrapartition parallelism) zapytanie jest podzielone w ramach partycji na kilka części, które mogą być wykonywane niezaleŝnie od siebie o Równoległość zewnętrzna (interpartition parallelism) zapytanie jest podzielone między serwery, gdzie kaŝdy serwer równolegle moŝe pracować nad swoją częścią zapytania o Równoległość wewnętrzna i zewnętrzna jednocześnie zapytanie jest dzielone między serwery, które pracują równolegle nad ich wykonaniem i dodatkowo na kaŝdym serwerze zapytanie jest dzielone na części, które są wykonywane równolegle. SELECT FROM SELECT FROM SELECT FROM Partycja bazy danych Partycja bazy danych Dane Dane Rysunek 14 - równoległość wewnętrzna i zewnętrzna 39

40 Równoległość operacji wejścia/wyjścia dyski na kaŝdym z serwerów mogą pracować równolegle Rysunek 15 - równoległość wejścia/wyjścia 5.2 Środowisko testowe Architektura systemu Na potrzeby testów rozproszenia bazy danych udostępnione zostały dwa identyczne serwery (nazwy domenowe w sieci to heplx65 i heplx66). Na obu serwerach zainstalowany został system operacyjny Linux Fedora Core release 8 (Werewolf) z podstawowym zestawem aplikacji oraz system bazy danych IBM DB2 Warehouse Base Edition: Product name: "DB2 Warehouse Base Edition" License type: "CPU" Expiry date: "Permanent" Product identifier: "dwbe" Version information: "9.5" Dodatkowo na jednym z serwerów (heplx66) do testów został zainstalowany system bazy danych PostgreSQL w wersji Parametry sprzętowe kaŝdego z serwerów są następujące: Pamięć RAM : 8GB Dwa procesory 4 rdzeniowe o następujących parametrach : vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 1.60GHz stepping : 11 cpu MHz :

41 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx tm2 ssse3 cx16 xtpr dca lahf_lm bogomips : clflush size : 64 4 dyski twarde o pojemności 500GB kaŝdy o następujących parametrach: Disk GB, bytes 255 heads, 63 sectors/track, cylinders Units = cylinders of * 512 = bytes Architektura systemu przedstawia się następująco : Rysunek 16 architektura systemu testowego 41