Miraastroforum

Witam,

Czy ktoś z Was wykorzystuje jakieś bazy danych do przechowywania swoich wyników obserwacji, a jeśli tak to jakie?
Czy raczej tylko excel?

W nadchodzącej nowej wersji DOGZ-a obserwacje będą zapisywane w bazie danych SQLite. Jej główną zaletą jest zgodność z SQL-em, bez konieczności instalowania osobnego oprogramowania serwera. Ponadto jest wtyczka do Firefoxa która umożliwia szybkie podglądnięcie bazy

antyqjon napisał(a):W nadchodzącej nowej wersji DOGZ-a obserwacje będą zapisywane w bazie danych SQLite.

Jest więc okazja zastanowić się nad taką oto propozycją:

Na naszym październikowym seminarium planuję przedstawić wykład o bazach danych w obserwacjach gwiazd zmiennych. Myślę też trochę nad napisaniem jakichś programów dla nas, które by nam pomogły w obserwacjach. Dlatego moja propozycja: może wspólnie pomyślimy nad minimalną wersją schematu bazy danych jaka by obowiązywała w PTOGZ?
Byłby to swego rodzaju nasz standard Jeśli ktoś chciałby napisać jakiś program to musiałby bazować właśnie na tym wymaganym minim.

Mając ustalony standard nie mielibyśmy najmniejszego problemu z wymianą danych (wyników obserwacji) Wtedy ograniczałaby nas tylko nasza wyobraźnia

Strona PTOGZ oczywiście też by korzystała z tego minimum, ale oczywiście tutaj schemat bazy danych byłby znacznie większy (zawierałby jednak to wymagane minimum).

Z zawodu jestem informatykiem, po systemach baz danych na Politechnice Poznańskiej. Chętnie więc tutaj bym zobaczył jakiś zespół pracujący nad tym naszym standardem bazodanowym O XML'u nie wspomnę bo to się rozumie samo przez się
Hmm właśnie wpadłem na pomysł drugiego wykładu jaki mógłbym wygłosić - na temat XML i wymiany danych za jego pomocą

Może się mylę, ale myślę, że jakbyśmy tak mieli się teraz powymianiać naszymi wynikami to byłoby niezłe zamieszanie, a tak XML + nasz standard i po kłopocie.

Opracowując nasz standard trzeba by było zobaczyć co do tej pory jest zrobione, jakie bazy już posiadamy, do jakich mamy dostęp itd. Tak aby nie odkrywać koła na nowo , a jedynie nasz standard dostosować do naszych potrzeb

Zapraszam gorąco do dyskusji.

Zeszło mi prawie tydzień odkąd obiecałem coś napisać, ale cóż, ostatnie tygodnie studiowania, wariacki czas... Na szczęście dziś piątek wieczór, wręcz nie wypada się uczyć, to dodam moje 0.03 PLN na temat baz danych.

Osobiście mam pewne doświadczenie z MySQL-em, Postgresem i SQLite, na potrzeby nowej wersji DOGZ-a (o tym więcej wkrótce, w innym wątku) wybrałem ten ostatni system. Zacytuję samego siebie, z mojej pracy inżynierskiej:

System SQLite (http://www.sqlite.org) prezentuje odmienne podejście. Nie występuje tu architektura klient-serwer, twórcy tego systemu nazywają go bezserwerowym (ang. serverless). Zamiast tego cała funkcjonalność bazy danych jest dołączona do programu, który tej bazy używa – obrazuje to rysunek 14. Cały kod „serwera”, czyli procedury realizujące obsługę zapytań SQL, mieści się w niewielkiej bibliotece dołączanej do programu (istnieje możliwość linkowania statycznego, więc użytkownik oprogramowania nawet nie musi nigdzie widzieć tej biblioteki). Unika się w ten sposób problemu „wąskiego gardła”, jakim w przypadku typowych systemów baz danych jest komunikacja pomiędzy klientem a serwerem. W przypadku opóźnień łącza internetowego, bądź dużego obciążenia sprzętu, na którym jest uruchomiony proces serwera, oczekiwanie na odpowiedź może trwać bardzo długo i doprowadzić do zawieszenia się programu klienta, lub po prostu do odrzucenia wykonywanej operacji. Gdy natomiast zapytanie jest wykonywane natychmiastowo przez program, który je zgłosi, problem opóźnień może dotyczyć niemal wyłącznie operacji dyskowych.

Kolejną istotną różnicą pomiędzy SQLite a innymi systemami jest sposób przechowywania danych. W konkurencyjnych systemach baz danych struktura dyskowa tabel jest często skomplikowana, a nawet przypadkowa modyfikacja bądź usunięcie jednego pliku potrafi uniemożliwić dostęp do całej bazy. W SQLite obowiązuje zasada: jedna baza danych – jeden plik. Wewnątrz pliku znajdują się wszystkie definicje struktur, tabel, indeksów, perspektyw, a także właściwe dane. Ułatwia to przenoszenie danych pomiędzy aplikacjami – wystarczy skopiować plik bazy danych, podczas gdy inne systemy wymagają często osobnych narzędzi do eksportu i importu.

SQLite jest też wyjątkowe z innego powodu. Rezygnacja z architektury klient-serwer oznacza brak konieczności instalacji oprogramowania serwera, oraz późniejszej konfiguracji oraz zarządzania serwerem. Integracja silnika bazy danych z oprogramowaniem klienta upraszcza instalację i redukuje zależność od zewnętrznych programów. Jedyne o co należy zadbać przy instalacji, to dostarczenie struktury tabel wykorzystywanych w oprogramowaniu klienta.

Tyle o samym systemie. Natomiast, nad strukturą bazy też się trochę zastanawiałem, porównując informacje jakie zbieramy w PTOGZ czy w bazie SSW, oraz w AAVSO.

Obecnie w PTOGZ struktura głównej tabeli, czyli obserwacji, wygląda tak:

Kod: Zaznacz cały

CREATE TABLE obserwacje (id int(10) NOT NULL auto_increment, kod char(3), jd double, gwiazda char(12), jasnosc double ... (reszta nieistotna)

Mamy zatem kod obserwatora, JD, nazwę gwiazdy i jasność - czyli absolutne minimum. Amerykanie gromadzą zdecydowanie więcej danych o pojedynczej obserwacji, np. gwiazdy porównania, filtry, oznaczenia mapek itp. Dodatkowo mają rozróżnienie na obserwacje wizualne i fotometryczne. Wygląda to tak:

Wizual:
• Identyfikator: nazwa gwiazdy, albo desygnacja, albo AUID
• Data: JD, czas UT, albo format Excela
• Jasność w mag. (z kropką dziesiętną)
• Słabsza niż (opcjonalnie)
• Gwiazda porównania 1 (jasność bez kropki, wymagana)
• Gwiazda porównania 2 (jasność bez kropki, opcjonalna)
• Data mapki (format YYMMDD)
• Literowe kody komentarzy (np. B – bright sky, Y – outburst)
• Uwagi (max. 100 znaków)

Foto:
• Identyfikator: nazwa gwiazdy, albo desygnacja, albo AUID
• Data: JD, HJD, czas UT, albo format Excela
• Jasność w mag. (z kropką dziesiętną)
• Słabsza niż (opcjonalnie)
• Błąd magnitudo (z kropką dziesiętną, bez znaku)
• Typ jasności (różnicowa, standardowa) ??
• Literowe kody komentarzy (np. B – bright sky, Y – outburst)
• Czy przekształcono (tak, nie)
• Rodzaj filtra
• Gwiazda porównania (AUID albo oznaczenie z mapki – jasność bez kropki)
• Jasność gwiazdy porównania
• Gwiazda kontrolna (AUID albo oznaczenie z mapki – jasność bez kropki)
• Jasność gwiazdy kontrolnej
• CCD czy fotometr?
• Airmass
• Data mapki (format YYMMDD)
• Uwagi (max 100 znaków)

Pogrubiłem cechy wspólne dla obu typów obserwacji. Na dodatek pogrubioną kursywą oznaczyłem te kolumny, które mniej więcej pokrywają się z naszymi tabelami obserwacji. Stąd przyszedł mi do głowy pomysł na taką strukturę, złożoną z 3 tabel (to tylko szkic kolumn tabeli):

base_observation:
id, star_name, jd, magnitude, fainter_than, comp_star_name (=NULL), chart_date (=NULL), comment_codes (=NULL), notes (=NULL)
visual_observation:
id, base_observation_id, second_comp_star_name (=NULL)
photo_observation:
id, base_observation_id, magnitude_error, magnitude_type, transformed, filter_type, comp_star_magnitude, check_star_name, check_star_magnitude, ccd_or_pep, airmass

Dwie ostatnie tabele są w relacji 1:1 z tabelą base_observation. Tym sposobem mamy swego rodzaju "dziedziczenie". Chociaż w zasadzie nie ma większego sensu wydzielanie osobnej tabeli tylko dla drugiej gwiazdy porównania... możnaby ją przenieść do podstawowej tabeli jako kolejną domyślnie nullową kolumnę. Nie jestem specem od normalizacji, więc chętnie poznam opinię fachowca od BD

Dlaczego tyle kolumn? Bo zakładam, że DOGZ2 będzie obsługiwał zarówno naszą bazę, jak i umożliwiał współpracę z AAVSO, w tym opracowanie fotometrii CCD. Jeśli ktoś sobie zażyczy, będzie miał możliwość dodawania w programie tych wszystkich dodatkowych informacji. A skoro już o nowym DOGZ-ie mowa, to pewną działającą wersję "bardzo alfa" już piszę i wkrótce coś więcej powiem na ten temat.

Poza tym widzi mi się również nowa wersja strony PTOGZ, ale to w późniejszym czasie... po prostu aż głupio mi patrzeć na niektóre moje potworki w kodzie strony Nabrałem conieco doświadczenia we frameworkach (symfony, Django), może coś w tą stronę podziałamy - ale to też temat na osobny wątek, dobra, dość tego elaboratu

Cały czas myślę nad tym połączeniem www z sqlite i jakoś nie bardzo to do mnie przemawia. Sam twórca sqlite mówi, że ten system baz danych powstał raczej jako zamiennik fwrite() a nie jak system baz danych z prawdziwego zdarzenia jak np. postgresql.

W jakimkolwiek opisie sqlite czytamy jakie są zastosowania sqlite i jak jasno wynika, że system ten powstał z myślą o dołączaniu tego do aplikacji. np. Android, Apple iPhone, itd. Zatem system ten ma wyraźne przeznaczenie i nie jest nim na pewno www, aczkolwiek sprawdza się jakoś i tu

Piszesz, że masz doświadczenie z postgresql. Czy zatem może być lepszy wybór niż postgresql lub mysql?

Tak, tak wiem, już podjąłeś decyzję więc moje pisanie jest pisaniem do szuflady

To były moje 0,03 zł na temat wyboru systemu baz danych.

Co do struktury bazy to fajnie by było jakbyśmy mieli sposobność obgadania tematu na żywo np. na seminarium. Obawiam się jednak, że do tego czasu będziemy już mieć nową stronę i strukturę bazy

Oczywiście jeśli chcesz mogę przygotować diagram ER i podesłać tutaj celem poddania go dalszej dyskusji, itd. W końcu co dwie głowy to nie jedna

Zrezygnowałem z diagramu ER i od razu podaję stosowne zapytania
W razie pytań pisz śmiało. SQL oczywiście napisany pod SQLite Mam nadzieję, że referencje napisałem poprawnie w SQLite.
PS: szkoda, że SQLite nie ma typu danych enum. Jest obejście na to w postaci triggera, ale zawsze to obejście, a nie docelowe rozwiązanie.

Tak się zastanawiam czy nie byłoby lepiej oprócz nazwy gwiazdy dodać jeszcze jedno pole z skrótem gwiazdozbioru. To się może przydać w przypadku selectów typu np.: pokaż obserwacje gwiazdek z gwiazdozbioru AND
Można też rozbić nazwę zmiennę na jej faktyczną nazwę np. R i gwiazdozbiór w którym leży np. TRI. I tu właśnie mamy temat do przedyskutowania

Oto moja propozycja relacji (tabelek) w bazie danych:

/*Visual or Photographic Observations */
CREATE TABLE "main"."vphobservations" (
"id_obs" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL ,
"id_czl" INTEGER NOT NULL, /* id of observer from table observers */
"star_name" VARCHAR NOT NULL ,
"jd" VARCHAR NOT NULL ,
"ut" DATETIME NOT NULL ,
"mag" FLOAT NOT NULL ,
"fainter" CHAR NOT NULL DEFAULT 'n', /* n – no, y – yes */
"comp1" FLOAT NOT NULL ,
"comp2" FLOAT NOT NULL ,
"chart" VARCHAR,
"comCode" CHAR,
"notes" TEXT,
"obsType" CHAR NOT NULL DEFAULT 'v', /* v – visual, f – photographic */
FOREIGN KEY (id_czl) REFERENCES observers (id_man)
)


/*CCD or PEP Observations */
CREATE TABLE "main"."ccdpepobservations" (
"id_obs" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL ,
"id_czl" INTEGER NOT NULL, /* id of observer from table observers */
"star_name" VARCHAR NOT NULL ,
"jd" VARCHAR NOT NULL ,
"ut" DATETIME NOT NULL ,
"fainter" CHAR NOT NULL DEFAULT 'n', /* n - no, y - yes */
"mag_err" FLOAT NOT NULL ,
"mag_type" CHAR NOT NULL DEFAULT 's', /* s-standard, d – differential */
"comCode" CHAR,
"trans" CHAR NOT NULL DEFAULT 'n', /* n – no, y – yes */
"filter" VARCHAR,
"comp_label" VARCHAR NOT NULL ,
"comp_mag" FLOAT NOT NULL ,
"check_label" VARCHAR NOT NULL ,
"check_mag" FLOAT NOT NULL ,
"airmass" FLOAT NOT NULL ,
"group" INTEGER,
"chart" VARCHAR NOT NULL ,
"notes" TEXT NOT NULL ,
"obsType" CHAR NOT NULL DEFAULT 'c', /* c – ccd, p - pep*/
FOREIGN KEY (id_czl) REFERENCES observers (id_man)
)


/* Observers */
CREATE TABLE "main"."observers" (
"id_man" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL ,
"aavsoid" VARCHAR, /* observer’s AAVSO code */
"name" VARCHAR NOT NULL ,
"surname" VARCHAR NOT NULL ,
"city" NOT NULL,
"id_sc" INTEGER NOT NULL, /* id of telescope from table telescopes */
FOREIGN KEY (id_sc) REFERENCES telescopes (id_scope)
)


/* Telescopes */
CREATE TABLE "main"."telescopes" (
"id_scope" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL ,
"aperture" FLOAT NOT NULL,
"scopeType" CHAR NOT NULL DEFAULT 'n' /* n – newton, b – binoculars, r – refractor, m – maksutov, o - other */
)

Myślę, że wszystko zmierza ku temu, by format pliku z obserwacjami był zgodny (kompatybilny) z systemem AAVSO. I tak byłoby najlepiej, raporty można by słać od razu do AAVSO i PTOGZ bez potrzeby przerabiania pliku tekstowego.

Nie zawsze dla danej gwiazdy AUID jest nadany, czasami się zdarza, że nawet w VSX gwiazdy w bazie nie mają. Stara wersja formatu AAVSO proponuje wpisywanie kodu 9999+99 jeżeli nie ma kodu harwardzkiego.
Nawet gdy ów jest nadany, podanie kodu 9999+99 nie powoduje odrzucenia raportu.
Zatem, może by i w naszym przypadku zastosować ten "wybieg".

Obecnie wysyłam obserwacje w starej wersji; PCObs nijak nie chce przyjmować numeru mapki przy włączonej opcji sprawdzania błędów, zatem kolejna propozycja: jeżeli nie ma numeru mapki (czasami korzystamy z własnoręcznie wykonywanych mapek - można by wpisywać "na" lub 999999.

Z nazwa gwiazdozbioru można by się uporać następująco: przecież w raporcie nazwę zmiennej piszemy, podając jedną, lub 2 litery bądź cyfry, a potem po jednej spacji idzie nazwa gwiazdozbioru. Może dałoby się zrobić tak, by soft czytający plik tekstowy raportu rozpoznawał te pola i właśnie stąd brał nazwę gwiazdozbioru.

Panie Emilianie,

Również uważam, że powinniśmy być zgodni z AAVSO tzn, przetrzymywać w bazie danych te pola które wymaga AAVSO. Część z tych pół jest akurat wykorzystywana przez SSW, więc od razu za jednym zamachem mamy załatwione dwie instytucje ba, nawet trzy, bo przecież nasz PTOGZ

Również jestem za pomysłem z dziewiątkami.

Co do nazwy gwiazdozbioru: czy będzie jedno pole postaci "R Tri" czy dwa pola "R" oraz "Tri" zależy od tego jakie zapytania będą szły do bazy danych. Z bazodanowego punktu widzenia lepiej byłoby to rozbić na dwa pola. Bardzo, ale to bardzo by to potem uprościło cokolwiek, łącznie z późniejszymi raportami statystykami itd. gdyby były dwa pola.

Adres zamieszkania z bazie danych tez nie składa się z jednego pola adres tylko np. z pola ulica, z pola nr domu, z pola nr lokalu, z pola kod pocztowy, z pola miasto itd

Nie jestem mocny w pisaniu dlatego mam nadzieję przedyskutować ten temat na żywo na seminarium. Mam nadzieję, że Pan będzie