Technologia In-Place Database Processing (IDP)


Cele i korzyści ze stosowania technologii IDP

Wstęp. In-Place Database Processing (IDP) jest zaawansowaną technologią dostępu do baz danych rozwijaną przez StatSoft wspierającą wysokiej jakości, bezpośredni interfejs pomiędzy zewnętrznym zbiorem danych ulokowanym na zewnętrznym serwerze a narzędziami analitycznymi programów z rodziny STATISTICA. Technologia IDP została wprowadzona w celu ułatwienia dostępu do dużych zbiorów danych w dużych bazach danych. Do tego celu wykorzystywany jest krokowy proces, który nie wymaga tworzenia lokalnej kopii danych. Technologia IDP znacznie poprawia osiągi wydajnościowe programu STATISTICA ; jest to szczególnie istotne w zadaniach dotyczących rozbudowanych projektów data mining i eksploracyjnej analizy danych.

Źródła korzyści ze stosowania technologii IDP. Wzrost wydajności obliczeń po zastosowaniu technologii IDP – w porównaniu z tradycyjną metodą dostępu do danych – wynika nie tylko z bezpośredniego dostępu programów z rodziny STATISTICA do dużych ilości danych umieszczonych w bazach danych bez konieczności tworzenia ich kopii na lokalnej stacji roboczej, ale również z „wielozadaniowości” systemu. Mówiąc dokładniej, IDP wykorzystuje możliwości przetwarzania danych (maszyny wieloprocesorowe) serwerów baz danych do wykonywania zapytań, wydobywa w ten sposób określone dane ze zbioru danych, a następnie wysyła je do komputera, na którym zainstalowany jest program STATISTICA, który przetwarza kolejno nadchodzące dane.

Kompatybilność z programami z rodziny STATISTICA

Technologia IDP może być stosowana zarówno w wersji stanowiskowej jak i korporacyjnej programu STATISTICA. W obu przypadkach jest w pełni kompatybilna z architekturą klient/serwer systemu STATISTICA Enterprise Server (taki wymóg musi być spełniony przy dostępie do Internetu i asynchronicznym przetwarzaniu danych przez serwer STATISTICA Enterprise Server połączony z serwerem bazy danych, stanowiącym następną warstwę, który wykonuje zapytania). Technologia IDP jest zoptymalizowana i zintegrowana z systemem STATISTICA Data Miner, który może wykorzystywać w projekcie data mining wiele źródeł danych IDP.

Architektura i programowalność

Technologia In-Place Database Processing bazuje na obiektowym modelu COM, który jest technologią firmy Microsoft stanowiącą fundament dla obiektów ActiveX Data Object (ADO). Technologia COM umożliwia dostęp do różnych obiektów, w tym arkuszy danych STATISTICA za pomocą biblioteki obiektów STATISTICA . Wszystkie analizy programu STATISTICA mają dostęp do danych w arkuszu danych poprzez interfejs arkusza danych. (Aktualnie jest to obiekt o nazwie InputSpreadsheet, który posiada metody interfejsu skoroszytu. Interfejs InputSpreadsheet normalnie jest ukryty w przeglądarce obiektów, możemy go jednak uwidocznić klikając prawym klawiszem myszki w polu przeglądarki obiektów i wybierając polecenie „Pokaż ukryte”). Dlatego też, z punktu widzenia analiz w STATISTICA, tabela IDP wygląda dokładnie tak samo jak arkusz danych. Zaawansowani użytkownicy programu STATISTICA mogą korzystać z interfejsu InputSpreadsheet w odniesieniu do wszystkich źródeł danych, i wykonywać analizy STATISTICA przy pomocy narzędzi programistycznych korzystając jednocześnie z obiektowego modelu programu STATISTICA.

W celu nadania analizie spójności, nieodzowne jest skorzystanie z obiektów arkusza danych. Na przykład, jeżeli do przeprowadzenia analizy potrzebna jest informacja o liczbie przypadków w zbiorze danych, najpierw wykonywane jest zapytanie zwracające liczbę przypadków (analiza zostaje wstrzymana do momentu otrzymania informacji o liczbie przypadków w zbiorze danych). To środowisko jest modyfikowalne przy pomocy opcji umieszczonych w oknie opcji programu STATISTICA . Jeżeli korzystamy z typu kursora określonego jako tylko w przód i analiza musi wielokrotnie przejrzeć dane lub wylosować tylko niektóre spośród danych, wówczas wymagana jest znajomość wartości poprzedniego przypadku (wiersza). W takim przypadku IDP wykonuje powtórnie zapytanie do bazy danych i przesuwa kursor w przód do wymaganego przypadku, ponieważ kursor nie może być przesuwany do tyłu. W tym czasie analiza oczekuje aż proces pobierania danych zostanie zakończony i analiza otrzyma komplet danych.

Biblioteka IDP posiada dwa interfejsy. DBTable umożliwia programistom dostęp do dokumentów IDP, tak jak interfejsy Macro, Graph, i Spreadsheet umożliwiają dostęp do makr, wykresów, i arkuszy danych programu STATISTICA . Dodatkowo standardowe metody i właściwości dokumentu (Visible, Activate, Close, itd.) umożliwiają korzystanie ze wszystkich określonych opcji IDP (typ kursora, położenie kursora, łańcuch tekstowy zapytania, itd.). Właściwość „Spreadsheet” jest typu „read-only” i zwraca opakowanie („wrapper”) obiektu ADO Recordset.

Drugi interfejs nosi nazwę DBSpreadsheet. IDP korzysta wewnętrznie z tego interfejsu w celu utworzenia opakowania („wrapper”) obiektu Spreadsheet. Ten interfejs może być wykorzystywany przez użytkowników piszących własne makra i programy, mimo że w wielu przypadkach interfejs DBTable jest wystarczającym. Interfejs DBSpreadsheet posiada dwie metody, Open i CreateNew. Metoda Open wykonuje zapytanie i otwiera ADO Recordset. Powoduje to utworzenie opakowania („wrapper”) obiektu Spreadsheet i dołączenie go do obiektu ADO Recordset. Po wykonaniu tych operacji metoda zwraca utworzony obiekt arkusza danych („Spreadsheet”). Metoda CreateNew tworzy opakowanie („wrapper”) obiektu Spreadsheet, który nie jest dołączany do Recordset, a zatem nie jest wykorzystywany dopóki nie zostanie wywołana metoda „SetRecordset”.

Najczęściej zadawane pytania

In-place Database Processing (IDP)  W jaki sposób działa In-place Database Processing (IDP)?

IDP tworzy obiekt, który implementuje interfejs COM arkusza danych STATISTICA. Obiekt ten stanowi opakowanie („wrapper”) dla obiektu Microsoft ADO Recordset, następnie wszystkie analizy STATISTICA otrzymują dostęp do danych arkusza przez ten interfejs. Utworzone opakowanie („wrapper”) wygląda tak samo jak inne arkusze danych przeznaczone do analizy.

In-place Database Processing (IDP) Dlaczego IDP wyświetla czasem tylko jeden przypadek spośród danych, podczas gdy określona jest w opcjach pobierania liczba n pierwszych przypadków?

Jeżeli korzystamy z typu kursora wyłącznie w przód, wówczas IDP nie może przesunąć Recordset poza pierwszy przypadek (wiersz), ponieważ informacja o pierwszych n wierszach zostałaby utracona. Jeżeli natomiast analiza wymaga tych danych, wówczas zapytanie wykonywane jest ponownie. Opcja Przeglądaj pierwsze n przypadków znajduje zastosowanie tylko wtedy, gdy korzystamy ze statycznego typu kursora.

Liczba przypadków Jaki jest cel wyboru „liczby przypadków” w oknie dialogowym Opcje programu STATISTICA?

Dokładna liczba przypadków może nie być jeszcze określona w momencie kiedy wymaga tego analiza. W takim przypadku, możliwe są dwa zdarzenia, w zależności od opcji, które wybierzemy. Albo wykonywane jest odrębne zapytanie zwracające liczbę przypadków, albo arbitralnie użytkownik określa górną granicę dla liczby przypadków do analizy.

Dokładna liczba przypadków Kiedy dokładna liczba przypadków nie jest znana?

W poniższych sytuacjach liczba przypadków nie jest znana:

    a) Kiedy korzystamy z typu kursora wyłącznie w przód
    b) Kiedy korzystamy ze statycznego typu kursora z asynchronicznym zapytaniem i/lub pobieramy zapytanie, i/lub pobieranie zapytania nie zostało jeszcze zakończone.

w przypadku kiedy korzystamy ze statycznego typu kursora z synchronicznym pobieraniem, to liczba przypadków będzie znana po wykonaniu zapytania.

Automatycznie wylicz liczbę przypadków Jakie są zalety/korzyści/wady wynikające z zastosowania opcji Automatycznie wylicz liczbę przypadków?

Kiedy liczba przypadków w analizowanym zbiorze danych nie jest znana a analiza wymaga tych informacji, i kiedy zastosujemy tę metodę, wówczas wykonywane jest odrębne zapytanie, a analiza czeka na jego wyniki. Jeżeli zapytanie jest skomplikowane, to cały proces przebiega wolniej. Dodatkowo, kiedy w bazie danych, do której wykonujemy zapytanie, zostały wprowadzone jakieś zmiany, to pobrane dane w kolejnym zapytaniu będą niekonsystentne; np., jeżeli ktoś dodał lub usunął rekordy w bazie danych, wówczas faktyczna liczba rekordów jest inna niż przedstawiona analizie. Zaletą natomiast jest to, że jeżeli zapytanie nie jest skomplikowane i dane w bazie danych nie są modyfikowane w momencie wykonywania zapytania, otrzymujemy dokładną liczbę przypadków bez konieczności korzystania z wolniejszego typu kursora.

Przyjmij mniej niż x przypadków Jakie są zalety/korzyści/wady wynikające z zastosowania opcji Przyjmij mniej niż [x] przypadków?

ta metoda pozwala uniknąć wykonywania odrębnego zapytania pozwalającego na określenie liczby przypadków w analizowanym zbiorze danych. Tu określamy liczbę przypadków arbitralnie, zyskując tym samym na szybkości procesu pobierania i analizowania danych. Jeżeli w zbiorze danych znajduje się więcej przypadków niż określonych przez nas, to te przypadki zostaną zignorowane w analizie. Jeżeli natomiast zbiór danych zawiera mniej przypadków niż zadeklarowano (i oczekuje ich analiza), wówczas brakujące przypadki zostaną potraktowane jako braki danych. Jeżeli w zbiorze danych znajduje się dużo mniej przypadków niż w Recordset określonym przez użytkownika, wówczas analiza straci czas na proces poszukiwania nieistniejących przypadków.

Kursor Co to jest kursor?

Kursor jest strukturą danych, w której przechowywane są wyniki zapytania. Typ kursora określa funkcjonalność dostępu do danych. Niektóre kursory umożliwiają poruszania się wyłącznie w przód po danych otrzymanych w wyniku zapytania, inne natomiast umożliwiają poruszanie się w przód i w tył. Najczęściej stosowanymi typami kursorów są statyczny, dynamiczny, wyłącznie w przód. STATISTICA In Place Database Processor wspiera typy kursorów wyłącznie w przód i statyczny.

Kursor statyczny Co to jest kursor statyczny?

Statyczny typ kursora umożliwia poruszanie się po danych zarówno w przód jak i w tył, umożliwiając w ten sposób losowy dostęp do danych. Ten typ kursora tworzy „zdjęcie” danych otrzymanych w wyniku zapytania – zmodyfikowane rekordy, dodane, lub usunięte z bazy danych po utworzeniu kursora nie będą uwzględnione. Statyczny typ kursora po stronie serwera może spowodować znaczne obciążenie dla systemu bazy danych. Typ kursora po stronie klienta może być tylko statyczny. Jeżeli analiza lub inny sposób korzystania z IDP wymaga losowego dostępu do danych, wówczas ten typ kursora jest wymagany.

Kursor wyłącznie w przód Co to jest kursor wyłącznie w przód?

Typ kursora wyłącznie w przód, prostszy typ kursora, porusza się tylko do przodu po danych otrzymanych w wyniku zapytania. Ten typ kursora nie pozwala wyjść poza bieżący rekord danych. Kursor tylko w przód umożliwia szybszy dostęp do danych niż statyczny typ kursora i powoduje mniejsze obciążenie systemu bazy danych. W kontekście IDP, jeżeli użytkownik lub analiza wymaga wielokrotnego lub losowego dostępu do danych, wówczas zapytanie musi powrócić do poprzedniego rekordu. Jeżeli w międzyczasie rekordy zostaną zmodyfikowane, dodane lub usunięte z bazy danych, to powtórne zapytanie zwróci inne dane lub inną liczbę rekordów. Jeżeli określona analiza lub inny sposób korzystania z IDP umożliwia jednorazowy dostęp do danych, wówczas ten typ kursora jest najbardziej optymalnym rozwiązaniem.

Kursor po stronie klienta Co oznacza położenie kursora po stronie klienta?

Kursor utrzymywany jest po stronie klienta (użytkownika) przez Microsoft ActiveX Data Objects (ADO) Cursor Engine. W tym przypadku wszystkie dane otrzymane w wyniku zapytania kopiowane są na lokalny komputer użytkownika. Kursor po stronie klienta może być tylko kursorem statycznym.

Położenie kursora po stronie serwera Co oznacza położenie kursora po stronie serwera?

Kursor jest utrzymywany przez serwer bazy danych. Na lokalny komputer użytkownika kopiowana jest tylko określona przez „wielkość bufora” liczba rekordów, a reszta pozostaje na serwerze. Za każdym razem kiedy wymagane są nowe rekordy, są one kopiowane na lokalny komputer. Ten typ kursora powoduje obciążenie systemu bazy danych, który musi przechowywać wszystkie rezultaty zapytania.

Typ i położenie kursora Który typ i położenie kursora jest najlepsze?

Odpowiedź na to pytanie zależy od wielu czynników, jak np. sposób korzystania z danych, jak często dane w bazie danych są modyfikowane, itd., tak więc nie ma na to pytanie jednoznacznej odpowiedzi. Ogólnie rzecz biorąc, najszybszy jest kursor po stronie serwera, wyłącznie w przód, ale jeżeli wymagany jest wielokrotny lub losowy dostęp do danych, to nieuniknione jest wykonywanie wielu zapytań znacznie obniżających wydajność tej metody, a dane w bazie danych mogą w międzyczasie ulec zmianie. Kursor po stronie klienta z asynchronicznym zapytaniem i asynchronicznym pobieraniem danych daje bardzo dobre osiągi, umożliwiając jednocześnie losowy dostęp do danych, a dane raz pobrane do analizy nie ulegną zmianie. Należy jednak pamiętać, że wszystkie rekordy zwrócone przez zapytanie zapisywane są na lokalnym dysku komputera.

Dynamiczny kursor Czy można w IDP użyć dynamicznego typu kursora?

Ten typ kursora, dostępny w ADO, nie jest wspierany przez interfejs IDP. Dynamiczny typ kursora posiada cechy umożliwiające uaktualnianie bazy danych lub oglądanie zmian wprowadzonych przez innych użytkowników. Jednakże te cechy nie są wymagane w technologii IDP ponieważ w tym przypadku nie modyfikuje się bazy danych. Ponadto cechy, które posiada dynamiczny kursor sprawiają, że korzystanie z niego spowalnia proces pobierania i przetwarzania danych, w porównaniu z kursorami statycznym i wyłącznie w przód. Korzystanie z kursora typu dynamicznego w IDP jest możliwe, jednak trzeba do tego celu wykorzystać narzędzia programistyczne i skorzystać z modelu obiektowego IDP.

Wielkość bufora Co to jest „Wielkość bufora”?

Kiedy korzystamy z kursora po stronie serwera, liczba ta określa ilość rekordów jakie mają być przechowywane lokalnie na komputerze użytkownika. Kiedy wymagane rekordy nie znajdują się na lokalnym komputerze, wówczas ADO Recordset musi pobrać te dane z zewnętrznej bazy danych.

Zapytanie asynchroniczne Co oznacza „Zapytanie asynchroniczne”?

IDP nie czeka na koniec wykonywania zapytania, żeby dalej sterować programem STATISTICA. Zanim zapytanie zostanie wykonane, program nie posiada informacji na temat wyników polecenia Recordset; natomiast po wykonaniu zapytania, znana jest liczba pól (zmiennych), wraz z ich nazwami. W zależności od typu kursora, liczba rekordów (przypadków) może być znana lub nie. Po kompletnym wykonaniu zapytania, poszczególne rekordy mogą być pobierane z kursora. Kiedy korzystamy z tej cechy, możemy kontynuować pracę z programem STATISTICA lub rozpocząć nowe analizy z wykorzystaniem IDP zanim zapytanie zostanie ukończone. Naturalnie, jeżeli rozpoczniemy analizę przed ukończeniem zapytania, to analiza zaczeka do momentu ukończenia zapytania. Wskazane jest stosowanie tej opcji, głównie ze względu na niską złożoność zapytania.

Pobieranie asynchroniczne Co oznacza „Pobieranie asynchroniczne”?

„Pobieranie” to proces kopiowania wszystkich rekordów na lokalny komputer; zatem, opcja ta dostępna jest jedynie w przypadku kursora po stronie klienta. Kiedy korzystamy z tego typu kursora, ADO w tle wykonuje określone zapytanie i otwiera wewnętrznie kursor wyłącznie w przód. Ta sytuacja sprawia, że wszystkie dane z takiego typu kursora są kopiowane na lokalny komputer. Kiedy operacja kopiowania wykonywana jest synchronicznie, wówczas wszystkie inne operacje zostają zawieszone do czasu skopiowania wszystkich rekordów na lokalny komputer. Natomiast przy asynchronicznym pobieraniu danych, pobieranie odbywa się pomiędzy wykonywaniem poszczególnych zadań przez program, tak więc działanie programu może trwać nadal. Poszczególne rekordy są dostępne w miarę ich pobierania, jeżeli natomiast analiza wymaga rekordu, który nie został jeszcze pobrany, wówczas analiza zostaje „zawieszona” (czeka) do czasu jego pobrania. Tak więc, kiedy korzystamy z tej opcji, IDP nie czeka aż wszystkie rekordy zostaną skopiowane na lokalny komputer. Możemy więc kontynuować prace z programem STATISTICA lub rozpocząć nową analizę z wykorzystaniem tego samego źródła danych IDP zanim jeszcze zostaną pobrane wszystkie rekordy. Analiza rozpoczęta na Recordset, który jest w trakcie pobierania danych, będzie wstrzymywana zawsze kiedy będzie wymagać rekordów, które nie zostały jeszcze pobrane. Opcja ta jest proponowana nie tylko ze względu na możliwość kopiowania na lokalny komputer tylko kilku rekordów, ale również ze względu na to, że przy synchronicznym przesyłaniu setek lub tysięcy rekordów program STATISTICA byłby zajęty do czasu ukończenia pobierania danych.

Maksymalna liczba rekordów Dlaczego opcja „Maksymalna liczba rekordów zwracana przez zapytanie” nie zawsze działa?

ta opcja odnosi się do technologii ADO, która nie jest aktualnie implementowana, dlatego też przekazywana jest do dostawcy OLE DB. Aktualnie opcja ta jest dostosowana do OLE DB Provider for SQL Server, SQL Server ODBC Driver, jak również OLE DB Provider for Oracle i ODBC Driver for Oracle.

Obiekt ADO Recordset Chcę z poziomu języka programowania utworzyć własny obiekt ADO Recordset i dołączyć go do instancji IDP, na której będę wykonywał analizy w STATISTICA. Czy to jest możliwe?

Tak. Do tego celu należy użyć metody CreateNew z DBSpreadsheet, która zwraca obiekt arkusza danych, a następnie wywołać funkcje SetRecordset tego obiektu w celu dołączenia go do istniejącego ADO Recordset. Alternatywną metodą jest skorzystanie z właściwości arkusza danych interfejsu DBTable w celu pobrania arkusza danych i ustawienia na nim Recordset.

STATISTICA Visual Basic Piszę kod w STATISTICA Visual Basic dostając się do bazy danych przez interfejs Spreadsheet dostarczony przez IDP. Niektóre z metod arkusza danych nie działają. Dlaczego?

Nie wszystkie metody/właściwości interfejsu arkusza danych zostały zaimplementowane w arkuszu danych IDP. Wiele z nich w tym przypadku nie miałoby sensu lub nie może być zaimplementowanych. Generalnie, nie można wywołać metod i właściwości arkusza danych służących do modyfikowania danych, ponieważ w tym przypadku dane mają charakter tylko do odczytu.