Usługi heterogeniczne techniki integracji rozproszonych baz danych różnych producentów

Transkrypt

1 XI Konferencja PLOUG Kościelisko Październik 2005 Usługi heterogeniczne techniki integracji rozproszonych baz danych różnych producentów Robert Wrembel Politechnika Poznańska, Instytut Informatyki Streszczenie System informatyczny jest jednym z ważniejszych komponentów architektury informatycznej firmy. Jego nieodzowną częścią składową jest baza danych. Praktyka pokazuje, że w obrębie tej samej firmy jest często wykorzystywanych wiele baz danych pochodzących od różnych producentów, z których każda przechowuje pewną część istotnych danych gromadzonych i przetwarzanych w firmie. Bazy pochodzące od różnych producentów (np. Oracle, IBM, Sybase, Microsoft zwykle posiadają różną funkcjonalność, wykorzystują różną reprezentację danych i dialekty języka SQL. W konsekwencji, zintegrowany dostęp do wszystkich baz danych w firmie jest utrudniony. Dostawcy oprogramowania systemów baz danych oferują różnego rodzaju programy/sterowniki umożliwiające dostęp do wielu różnych źródeł danych. W ramach niniejszego artykułu zostaną omówione dwa podstawowe typy takich programów, tj. gateway'e (bramki i sterowniki OLE DB/ODBC zilustrowane przykładem integracji: (1 czterech baz danych, tj. Oracle10g, Sybase Adaptive Server Anywhere, SQL Server 2000, IBM DB2, w architekturze "każda z każdą", (2 oprogramowania MS Access, (3 plików tekstowych i dbf. Informacja o autorze Robert Wrembel: por. referat "Porównanie wydajności hurtowni danych ROLAP i MOLAP w Oracle 10g".

2

3 Usługi heterogeniczne techniki integracji rozproszonych baz danych różnych producentów Wprowadzenie Praktyka budowy i użytkowania systemów informatycznych w przedsiębiorstwach i wszelkiego rodzaju instytucjach pokazuje, że nawet w ramach jednej instytucji wykorzystuje się różnego rodzaju systemy gromadzenia, przetwarzania i analizy danych. Systemy te są heterogeniczne, co oznacza, że: posiadają różną funkcjonalność, np. funkcjonalność zapewnianą przez profesjonalne systemy zarządzania bazami danych (m.in. Oracle9i/10g, SQL Server2000, IBM DB2, Sybase Adaptive Server Enterprise, funkcjonalność oferowaną przez systemy typu Access, dbase, FoxPro, itp., czy arkusze kalkulacyjne, bądź edytory tekstu; posiadają różne modele danych, np. relacyjne, relacyjno-obiektowe, obiektowe, semistrukturalne; wykorzystują różne technologie i języki implementacyjne (np. C++, Java, Cobol. Dodatkowo, poszczególne systemy są geograficznie rozproszone. Rozproszenie źródeł danych i ich heterogeniczność powodują, że dostęp do całego zbioru informacji, widzianego w sposób spójny, jest trudny i czasochłonny. Ważnym wymaganiem systemów informatycznych jest dostęp do informacji pochodzących zarówno z heterogenicznych baz danych, jak i ze źródeł innych niż bazy danych, np. arkusze kalkulacyjne, dokumenty tekstowe, pliki HTML, SGML, czy XML. Dostawcy oprogramowania systemów baz danych oferują dwa podstawowe moduły programowe umożliwiające dostęp do wielu różnych źródeł danych, tj. bramki (ang. gateway i sterowniki OLEDB/ODBC/JDBC Bramki Głównym problemem w zintegrowanym dostępie do źródeł danych jest ich heterogeniczność. Nawet jeśli źródła są bazami danych, to bardzo często są to bazy danych pochodzące od różnych producentów, a co za tym idzie, posiadające różną funkcjonalność, reprezentację danych i dialekt języka SQL. Z tego względu, dostęp z jednej bazy danych do innej musi być realizowany za pomocą dedykowanego oprogramowania dla tych baz. Oprogramowanie to nosi nazwę bramki (ang. gateway. Jego zadaniem jest: transformacja typów danych pomiędzy bazami danych, transformacja dialektów języka SQL; zapewnienie transakcyjnego dostępu do baz danych Sterowniki ODBC i OLE DB ODBC (ang. Open Database Connectivity jest standardem definiującym metody dostępu do baz danych, bez względu na technologię implementacyjną tych baz danych. Ujednolicone metody dostępu są implementowane w warstwie pośredniej pomiędzy aplikacją, a bazą danych. Warstwa ta nosi nazwę sterownika ODBC (ang. ODBC driver. Implementacyjnie, sterownik ODBC stanowi interfejs programistyczny API, czyli zbiór procedur i funkcji realizujących obsługę danych o funkcjonalności języka SQL. Wykorzystanie sterownika ODBC jest możliwe jedynie wówczas, gdy i aplikacja i baza danych wspierają wywołania API tego sterownika. OLE DB (ang. Object Linking and Embedding DataBase stanowi API, opracowane przez Microsoft, umożliwiające dostęp do różnych źródeł danych. W ramach tego API możliwa jest zarówno obsługa danych o funkcjonalności języka SQL, w standardzie ODBC, jak i innych źródeł danych nie posiadających funkcjonalności baz danych.

4 330 Robert Wrembel 1.3. Produkty komercyjne Wiodący producenci systemów baz danych dostarczają gateway e do wszystkich najważniejszych systemów. Przykładowo: Oracle dostarcza oprogramowanie o nazwie Transparent Gateways. Jego zadaniem jest zapewnienie dostępu i wymiany danych z większością komercyjnych systemów relacyjnych, m.in. IBM, Sybase, Microsoft. Sybase dostarcza oprogramowanie o nazwie EnterpriseConnect Data Access umożliwiające dostęp do baz danych Microsoft SQL Server, IBM DB2, Oracle i Informix (teraz IBM. Dodatkowo, Warehouse Studio udostępnia pakiet Power Stage wspierający automatyzację procesów ekstrakcji, transformacji i oczyszczania danych pochodzących z różnych źródeł. Oprogramowanie firmy Ingres o nazwie Enterprise Access umożliwia aplikacjom systemu Ingres dostęp do danych składowanych w innych relacyjnych (m.in. Sybase, Microsoft SQL Server, CA-Datacom, Oracle, Informix, CA-IDMS, DB2, Rdb, Allbase SQL i nie relacyjnych bazach danych (m.in. IMS, VSAM, CICS/VSAM, RMS. Oprogramowanie IBM DataJoiner, umożliwiające wczytywanie i transformowanie danych do formatu bazy DB2 ze źródeł relacyjnych i nie relacyjnych. Data Propagator Relational przy współpracy z Data Joiner pozwala na synchroniczne i asynchroniczne replikowanie danych pomiędzy bazami danych m.in. następujących producentów: Oracle, Sybase, Microsoft, Informix Testowa architektura integracyjna W ramach zrealizowanego projektu integracyjnego połączono: bazy danych czterech różnych producentów, tj. Oracle9i/10g, MS SQL Server, IBM DB2, Sybase Adaptive Server Anywhere (ASA; pliki tekstowe i dbf z wyżej wspomnianymi bazami danych. W celach testowych wykorzystano architekturę integracyjną przedstawioną na rysunku 1. Dostęp z bazy Oracle do SQL Server został zrealizowany z wykorzystaniem bramki, natomiast dostęp z SQL Server do Oracle został zrealizowany z wykorzystaniem sterownika OLE DB. Pozostałe komponenty systemu połączono za pomocą sterowników ODBC.

5 Usługi heterogeniczne techniki integracji rozproszonych baz danych różnych producentów 331 FEDERATED SERVERS MS SQL, ORACLE, SYBASE, ODBC DB2 INFORMATION INTEGRATOR Sybase ASA DB2 ORACLE TRANSPARENT GATEWAY FOR MSSQL ORACLE ODBC HETEROGENOUS SERVICES External Table REMOTE SERVERS (ORAODBC, MSSODBC, DB2ODBC, ODBC MSSQL Linked Server OLEDB ODBC Linked Server MS JET *.DBF *.TXT Rys. 1. Testowa architektura integracyjna 2. Integracja Oracle10g i SQL Server2000 Sposób wykorzystania bramek zostanie zilustrowany na przykładzie baz Oracle9i/10g i SQL Server Architektura integracyjna Podstawową architekturę integracyjną umożliwiającą obustronny dostęp pomiędzy bazami danych Oracle9i/10g i SQL Server2000 przedstawiono na rysunku 2. Komunikacja z bazy danych Oracle do SQL Server jest realizowana za pomocą oprogramowania gateway (Oracle Transparent Gateway for Microsoft SQL Server. Oprogramowanie to jest instalowane na tym komputerze na którym działa SQL Server. Drugim koniecznym komponentem instalowanym na tym komputerze jest oprogramowanie sieciowe Oracle (zwane Net8 lub Net Services, w zależności od wersji systemu. Poszczególne kroki komunikacji Oracle SQL Server są następujące:

6 332 Robert Wrembel 1. Wysłanie z bazy Oracle żądania dostępu do bazy SQL Server reprezentowanej usługą sieciową. 2. Odbiór żądania przez proces nasłuchu (listener znajdujący się na komputerze z bazą SQL Server. 3. Uruchomienie agenta (oprogramowania gateway przez proces nasłuchu. 4. Translacja polecenia SQL przez agenta i wysłanie go do bazy SQL Server. 5. Wykonanie polecenia przez SQL Server. 6. Przekazanie wyników do agenta. 7. Translacja wyników przez agenta. 8. Przesłanie wyników do bazy Oracle. Komunikacja z bazy danych SQL Server do Oracle jest realizowana z wykorzystaniem sterownika OLE DB po stronie SQL Server i procesu nasłuchu, po stronie Oracle (por. [NSRefG, NSAdmG, WrBę03]. Rys. 2. Architektura integracyjna baz danych Oracle i SQL Server Poszczególne kroki komunikacji SQL Server Oracle są następujące: 1. Wysłanie z bazy SQL Server żądania dostępu do obiektu serwera łączonego (ang. linked server. 2. Przekazanie żądania (po jego translacji przez sterownik OLE DB do bazy Oracle reprezentowanej usługą sieciową. 3. Odbiór żądania przez proces nasłuchu działający na komputerze z bazą Oracle. 4. Wykonanie polecenia przez Oracle. 5. Przekazanie wyników do SQL Server za pośrednictwem sterownika OLE BD Instalowanie oprogramowania gateway Oprogramowanie gateway do bazy SQL Server znajduje się na płycie instalacyjnej systemu Oracle9i/10g. Standardowo nie jest ono instalowane. Wskazanie gateway'a dla odpowiedniego systemu jest możliwe w jednym z kroków instalacji oprogramowania systemu zarządzania bazą

7 Usługi heterogeniczne techniki integracji rozproszonych baz danych różnych producentów 333 danych Oracle (por. rysunek 3. Oprogramowanie gateway należy zainstalować na komputerze, na którym działa SQL Server. Rys. 3. Okno wyboru oprogramowania gateway dla dostępnych systemów baz danych Po zainstalowaniu gateway'a do SQL Server, w katalogu %ORACLE_HOME% pojawia się podkatalog tg4msql z podkatalogami admin, bin, doc, trace Konfigurowanie dostępu z Oracle do SQL Server W celu skonfigurowania dostępu z bazy Oracle do SQL Server należy: 1. Skonfigurować proces nasłuchu Oracle po stronie SQL Server (plik listener.ora. 2. Skonfigurować proces agenta (gateway Oracle po stronie SQL Server (plik inittg4msql.ora. 3. Zdefiniować usługę sieciową po stronie bazy Oracle, realizującą dostęp do SQL Server (plik tnsnames.ora Kofigurowanie procesu nasłuchu po stronie SQL Server Konfigurowanie procesu nasłuchu po stronie SQL Server polega na określeniu parametrów tego procesu, w pliku %ORACLE_HOME%\network\admin\listener.ora. Przykładową zawartość takiego pliku przedstawiono poniżej. GATEWAYLIS = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP(HOST = dcs-robcio(port = 1529 (ADDRESS=(PROTOCOL=ipc(KEY=PNPKEY SID_LIST_GATEWAYLIS =

8 334 Robert Wrembel (SID_LIST = (SID_DESC = (SID_NAME = DCS-ROBCIO (ORACLE_HOME = C:\oracle\product\10.1.0\db_1 (PROGRAM = tg4msql CONNECT_TIMEOUT_GATEWAYLIS = 0 Omówienie wszystkich powyższych parametrów znacznie wykracza poza zakres niniejszego artykułu. Pełen ich opis Czytelnik znajdzie w [NSRefG, NSAdmG, WrBę03]. Proces nasłuchowy nazywa się GATEWAYLIS. Parametr PORT określa port komunikacji z procesem nasłuchu. Parametr SID_NAME określa nazwę instancji SQL Server. Nazwa instancji jest określana w momencie instalowania SQL Server. ORACLE_HOME wskazuje katalog domowy systemu Oracle, w którym znajduje się również oprogramowanie gateway. PROGRAM wskazuje na plik wykonywalny uruchamiający oprogramowanie agenta (gateway. W przypadku dostępu do SQL Server, agent jest uruchamiany programem tg4msql.exe Konfigurowanie agenta po stronie SQL Server W celu skonfigurowania procesu agenta (gateway po stronie SQL Server należy w katalogu %ORACLE_HOME\tg4msql\admin\ umieścić plik parametrów agenta. Wzorcowy plik znajduje się w tym katalogu i ma nazwę inittg4msql.ora. Korzystając z pliku wzorcowego należy utworzyć plik o nazwie init<instancja SQL Server>.ora. Zawartość przykładowego pliku dla instancji SQL Server o nazwie DCS-ROBCIO przedstawiono poniżej. HS_FDS_CONNECT_INFO=DCS-ROBCIO.Northwind HS_FDS_TRACE_LEVEL=OFF HS_FDS_RECOVERY_ACCOUNT=RECOVER HS_FDS_RECOVERY_PWD=RECOVER Najważniejszym parametrem jest HS_FDS_CONNECT_INFO. Wskazuje on parametry połączenia do instancji SQL Server. W powyższym przykładzie DCS-ROBCIO jest nazwą tej instancji, a Northwind jest nazwą bazy danych w ramach wskazanej instancji Zdefiniowanie usługi sieciowej dla SQL Server po stronie bazy Oracle System Oracle w standardowej konfiguracji wykorzystuje plik zawierający zbiór usług sieciowych umożliwiających dołączanie się do różnych baz danych (por. [NSRefG, NSAdmG, Wr- Bę03]. Połączenie z bazy Oracle do SQL Server będzie możliwe tylko wtedy, gdy w pliku tym znajdzie się odpowiednia usługa. Plik opisujący zbiór usług sieciowych ma nazwę tnsnames.ora i znajduje się w katalogu %ORACLE_HOME%\network\admin\. Przykładowy fragment pliku przedstawiono poniżej. DCS-ROBCIO = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP(HOST = dcs-robcio(port = 1529 (CONNECT_DATA = (SERVICE_NAME = DCS-ROBCIO (SERVER = DEDICATED (HS=OK

9 Usługi heterogeniczne techniki integracji rozproszonych baz danych różnych producentów 335 Znaczenie najważniejszych parametrów jest następujące. PROTOCOL, HOST, PORT, oznaczają odpowiednio protokół komunikacyjny, nazwę komputera, na którym działa proces nasłuchu (GA- TEWAYLIS w naszym przykładzie i port komunikacyjny z procesem nasłuchu. SERVICE_NAME wskazuje nazwę instancji SQL Server. Wartość tego parametru musi być identyczna z wartością SID_NAME zdefiniowaną w pliku listener.ora (por. punkt Realizowanie dostępu z Oracle do SQL Server Dostęp do bazy danych SQL Server z bazy Oracle jest możliwy wyłącznie z wykorzystaniem łączników bazy danych (ang. database links [OraSQL, WrBę03]. Obiekt typu łącznik w swej definicji zawiera nazwę usługi sieciowej realizującej dostęp do innej bazy danych. Może również zawierać nazwę i hasło użytkownika w innej bazie danych. Poniższe dwa polecenia tworzą łączniki odpowiednio o nazwach dbl_1_mssql i dbl_2_mssql. Pierwszy z nich w swej definicji zawiera tylko nazwę usługi sieciowej (using 'DCS-ROBCIO', pod którą jest dostępny SQL Server. W tym przypadku w bazie SQL Server musi istnieć użytkownik identyczny co do nazwy i hasła z użytkownikiem, który wykorzystuje łącznik. Drugi łącznik zawiera dodatkowo jawnie wskazanego użytkownika bazy SQL Server i jego hasło. Użytkownikiem tym jest scott z hasłem tiger. create database link dbl_1_mssql using 'DCS-ROBCIO'; create database link dbl_2_mssql connect to scott identified by tiger using 'DCS-ROBCIO'; Po utworzeniu łącznika dostęp do konkretnej tabeli w schemacie użytkownika jest realizowany za pomocą poleceń select, insert, update, delete bazy Oracle. Poniżej przedstawiono przykładowe polecenie odczytujące dane z tabeli test znajdującej się w bazie SQL Server, w schemacie użytkownika scott. select * from test@dbl_2_mssql; 2.4. Konfigurowanie dostępu z SQL Server do Oracle W celu skonfigurowania dostępu z bazy SQL Server do Oracle należy: 1. Zdefiniować usługę sieciową po stronie bazy SQL Server, realizującą dostęp do Oracle (plik tnsnames.ora. 2. Zdefiniować serwer łączony w SQL Server wykorzystujący usługę sieciową z pliku tnsnames.ora Zdefiniowanie usługi sieciowej Oracle po stronie bazy SQL Server Podobnie, jak omówiono w punkcie 2.3.3, po stronie bazy SQL Server należy zdefiniować usługę sieciową wskazującą na odpowiednią bazę Oracle. Usługę tę definiuje się w pliku %ORAC- LE_HOME%\network\admin\tnsnames.ora. Przykładową definicję usługi LAB10G przedstawiono poniżej. Umożliwia ona łączenie z komputerem dcs-zk, na którym pracuje baza danych LAB10G. LAB10G = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP(HOST = dcs-zk(port = 1529 (CONNECT_DATA = (SERVICE_NAME = LAB10G

10 336 Robert Wrembel (SERVER = DEDICATED (HS=OK Zdefiniowanie serwera łączonego w SQL Server W celu zrealizowania dostępu z SQL Server do Oracle, należy w bazie SQL Server utworzyć tzw. serwer łączony (ang. linked server. Można to wykonać na dwa sposoby. Pierwszy z nich polega na wywołaniu odpowiednich procedur systemowych, a drugi polega na wykorzystaniu kreatora serwera łączonego z wykorzystaniem pakietu MS Enterprise Manager. Poniżej przedstawiono przykłady wywołania procedur systemowych umożliwiające zdefiniowanie serwera łączonego. Procedura sp_addlinkedserver tworzy serwer łączony nadając mu nazwę LAB10G (pierwszy argument. Drugim argumentem jest rodzaj produktu, do którego odwołuje się serwer łączony. W naszym przykładzie jest to Oracle; jest to predefiniowana nazwa. Trzeci argument wskazuje na właściwy sterownik OLE DB (ang. OLE DB provider umożliwiający dostęp do bazy Oracle. W tym przypadku sterownik nazywa się MSDAORA; jest to predefiniowana nazwa. Czwartym argumentem jest nazwa usługi sieciowej umożliwiającej dostęp do bazy Oracle. Nazwa ta jest zdefiniowana w pliku tnsnames.ora po stronie SQL Server. Procedura sp_addlinkedsrvlogin umożliwia odwzorowanie użytkownika SQL Server w odpowiadającego mu użytkownika bazy Oracle. Pierwszym argumentem jej wywołania jest nazwa serwera łączonego, utworzona procedurą sp_addlinkedserver. Drugi argument, tj. false określa, że kolejne argumenty reprezentują odwzorowanie użytkowników obu systemów. W tym przypadku użytkownik sa, tj. bazy SQL Server, ma swój odpowiednik w bazie Oracle w postaci użytkownika scott z hasłem tiger. sp_addlinkedserver 'LAB10G', 'Oracle', 'MSDAORA', 'LAB10G' sp_addlinkedsrvlogin 'LAB10G', false, 'sa', 'scott', 'tiger' Drugi sposób definiowania serwera łączonego wykorzystuje narzędzie graficzne MS Enterprise Manager. Nowy serwer łączony definiuje się zaznaczając w nawigatorze obiektów węzeł Linked Servers, a następnie z menu podręcznego wybierając opcję New Linked Server (por. rysunek 4. Po jej wybraniu pojawi się okno umożliwiające określenie własności serwera łączonego (por. rys. 5 i odwzorowanie użytkowników (por. rys. 6.

11 Usługi heterogeniczne techniki integracji rozproszonych baz danych różnych producentów 337 Rys. 4. Definiowanie serwera łączonego z poziomu MS Enterprise Manager Rys. 5. Definiowanie własności serwera łączonego

12 338 Robert Wrembel Rys. 6. Definiowanie odwzorowania użytkowników Realizowanie dostępu z SQL Server do Oracle Dostęp do bazy danych Oracle z bazy SQL Server jest możliwy za pomocą zdefiniowanego wcześniej serwera łączonego. Przykładowo, poniższe zapytanie odczytuje dane za tabeli PRA- COWNICY znajdującej się w schemacie użytkownika SCOTT. LAB10G jest nazwą serwera łączonego. select * from LAB10G..SCOTT.PRACOWNICY 3. Integracja Oracle9i/10g ze źródłami pseudo-bazodanowymi Integracja Oracle ze źródłami danych, które nie są w pełni funkcjonalnymi bazami danych, np. dbase, czy Access jest możliwa z wykorzystaniem sterowników ODBC. Źródła te muszą być widoczne w postaci plików tego samego systemu plików na którym działa system Oracle Konfigurowanie środowiska dostępu z Oracle do plików dbase W celu skonfigurowania dostępu z bazy Oracle do danych zapisanych w plikach systemu dbase należy: 1. Zainstalować sterowniki ODBC po stronie bazy danych Oracle. 2. Zdefiniować źródło danych ODBC wskazujące na katalog zawierający pliki dbase. 3. Zdefiniować usługę sieciową po stronie bazy Oracle, realizującą dostęp do plików dbase (plik tnsnames.ora. 4. Skonfigurować proces nasłuchu Oracle realizujący dostęp do agenta usług heterogenicznych Oracle. 5. Skonfigurować agenta usług heterogenicznych. 6. Utworzyć łącznik bazy danych z wykorzystaniem zdefiniowanej w kroku 3 nazwy usługi sieciowej.

13 Usługi heterogeniczne techniki integracji rozproszonych baz danych różnych producentów Instalowanie sterowników ODBC dla Oracle Sterowniki ODBC znajdują się na płycie instalacyjnej systemu Oracle. W procesie instalacji należy zaznaczyć odpowiednie komponenty, jak pokazano na rysunku 7. Rys. 7. Instalowanie sterowników ODBC i OLE DB dla bazy danych Oracle Definiowanie źródła danych ODBC W celu zrealizowania dostępu do danych składowanych w plikach dbase należy zdefiniować źródło danych ODBC, wskazujące na katalog, w którym takie pliki się znajdują. Wykorzystuje się do tego celu aplikację Źródła danych ODBC, dostępną w Panel sterowania Narzędzia administracyjne. W zakładce System DSN należy nacisnąć przycisk Add. Pojawi się wówczas okno umożliwiające wybór odpowiedniego sterownika (por. rysunek 8. Należy wybrać Driver do Microsoft dbase i nacisnąć Zakończ. Spowoduje to pojawienie się okna parametrów źródła danych ODBC (por. rysunek 9. Należy w nim określić nazwę źródła danych, wersję systemu dbase i katalog, w którym znajdują się pliki dbase.

14 340 Robert Wrembel Rys. 8. Wybór sterownika Rys. 9. Konfigurowanie źródła danych ODBC dla plików dbase Definiowanie usługi sieciowej Usługę sieciową Oracle wskazującą na pliki dbase definiuje się w pliku %ORAC- LE_HOME%\network\admin\tnsnames.ora. Przykładowa definicja usługi o nazwie DBA- SE została przedstawiona poniżej. Parametr SID=DBASE jest umowną nazwą, do której odwołamy się w parametrach procesu nasłuchu. DBASE= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp(HOST=dcs-robcio(PORT=1521 (CONNECT_DATA=(SID=DBASE (HS=OK Konfigurowanie procesu nasłuchu Proces nasłuchu bazy danych Oracle konfiguruje się w pliku %ORAC- LE_HOME%\network\admin\listener.ora. Przykładowe parametry nasłuchu dla zdefiniowanej usługi o nazwie DBASE przedstawiono poniżej. Wartość parametru SID_NAME musi być identyczna z wartością SID zdefiniowaną w tnsnames.ora (czyli DBASE w naszym przy-

15 Usługi heterogeniczne techniki integracji rozproszonych baz danych różnych producentów 341 kładzie. Parametr PROGRM=hsodbc wksazuje na agenta (program hsodbc.exe realizującego dostęp do źródła danych ODBC, wskazanego w pliku parametrów konfiguracyjnych tego agenta. SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = DBASE (ORACLE_HOME = C:\oracle\product\10.1.0\db_1 (PROGRAM = hsodbc Konfigurowanie agenta usług heterogenicznych Plik parametrów konfiguracyjnych agenta usług heterogenicznych (hsodbc znajduje się w katalogu %ORACLE_HOME%\hs\admin. Standardowo, po zainstalowaniu sterowników ODBC znajduje się tam przykładowy plik konfiguracyjny o nazwie inithsodbc.ora. Każde źródło danych, do którego ma być realizowany dostęp musi mieć swój plik konfiguracyjny o nazwie init<nazwa źródła danych>.ora. Przy czym nazwa źródła danych jest określana wartością parametru SID_NAME pliku listener.ora. W naszym przykładzie plik konfiguracyjny będzie miał nazwę initdbase.ora. Jego zawartość przedstawiono poniżej. HS_FDS_CONNECT_INFO = rw_dbase_odbc HS_FDS_TRACE_LEVEL = on Parametr HS_FDS_CONNECT_INFO wskazuje na źródło danych ODBC, zdefiniowane w sposób omówiony w punkcie Realizowanie dostępu z Oracle do plików dbase W celu zrealizowania dostępu z bazy danych Oracle do danych przechowywanych w plikach dbase należy zdefiniować łącznik bazy danych, a następnie odwołać się do konkretnego pliku posługując się nazwą tego pliku i zdefiniowanym łącznikiem. Przykładowo, pierwsze z poniższych poleceń definiuje łącznik o nazwie link_dbase wskazujący na usługę DBASE (w pliku tnsnames.ora. Drugie polecenie umożliwia odczyt danych z pliku o nazwie dane1.dbf. create database link link_dbase using 'DBASE'; select * from dane1@link_dbase; Należy zwrócić uwagę, że opisany sposób dostępu umożliwia odczyt i zapis wszystkich plików w formacie dbase znajdujących się w katalogu wskazanym w definicji źródła danych ODBC. Kolejną ważną cechą omawianej technologii integracyjnej jest brak obsługi przetwarzania transakcyjnego Konfigurowanie środowiska dostępu z Oracle do bazy MS Access Procedura konfiguracyjna środowiska dostępu z bazy danych Oracle do bazy MS Access jest podobna do procedury opisanej w punkcie 3.1. Polega ona na: 1. Zainstalowaniu sterowników ODBC po stronie bazy danych Oracle. 2. Zdefiniowaniu źródła danych ODBC wskazujące na konkretny plik bazy Access. 3. Zdefiniowaniu usługi sieciowej po stronie bazy Oracle. 4. Skonfigurowaniu procesu nasłuchu Oracle. 5. Skonfigurowaniu agenta usług heterogenicznych. 6. Utworzeniu łącznika bazy danych.

16 342 Robert Wrembel Instalowanie sterowników ODBC omówiono w punkcie Definiowanie źródła danych ODBC przebiega podobnie, jak opisano w punkcie Jedyną różnicą jest konieczność wskazania konkretnego pliku Access, który będzie skojarzony ze źródłem. W konsekwencji, wszystkie tabele we wskazanym pliku będą mogły być adresowane poleceniami SQL. Przykładowe parametry źródła danych ODBC, o nazwie rw_access_odbc przedstawiono na rysunku 10. Przycisk Baza danych - Wybierz umożliwia wskazanie pliku Access. Rys. 10. Konfigurowanie źródła danych ODBC dla pliku Access Przykładowy wpis do pliku tnsnames.ora definiujący usługę sieciową o nazwie ACCESS przedstawiono poniżej. ACCESS= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp(HOST=dcs-robcio(PORT=1521 (CONNECT_DATA=(SID=ACCESS (HS=OK Przykładowy wpis do pliku listener.ora dla usługi o nazwie ACCESS przedstawiono poniżej. Należy zwrócić uwagę, aby wartości parametrów SID i SID_NAME były identyczne w obu plikach. SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = ACCESS (ORACLE_HOME = C:\oracle\product\10.1.0\db_1 (PROGRAM = hsodbc Przykładowy wpis do pliku parametrów agenta (hsodbc initaccess.ora przedstawiono poniżej. Parametr HS_FDS_CONNECT_INFO wskazuje na źródło danych ODBC skojarzone z plikiem Access. HS_FDS_CONNECT_INFO = rw_access_odbc HS_FDS_TRACE_LEVEL = on

17 Usługi heterogeniczne techniki integracji rozproszonych baz danych różnych producentów 343 Dostęp do tabel składowanych w pliku Access realizuje się za pomocą łącznika bazy danych, podobnie jak dla plików dbase. Poniżej zdefinowano przykładowy łącznik link_access wykorzystujący usługę ACCESS (plik tnsnames.ora, która z kolei poprzez proces nasłuchu i agenta realizuje dostęp do źródła danych ODBC o nazwie rw_access_odbc. create database link link_access using 'ACCESS'; 4. Integracja Oracle i IBM DB2 Dostęp pomiędzy bazą Oracle a DB2 zrealizowano w obu kierunkach z wykorzystaniem sterowników ODBC, jak pokazano na rysunku Połączenie Oracle DB2 Z bazy danych Oracle do DB2 dostęp będzie możliwy po zainstalowaniu na komputerze klienta dedykowanego sterownika dla DB2. Sterownik taki znajduje się na płycie instalacyjnej DB2 (por. rys. 11. Rys. 11. Instalacja sterownika ODBC dla DB2 Dalsza procedura konfiguracyjna przypomina tę opisaną w punkcie 3.2 i wymaga ona wykonania następujących czynności: 1. Skonfigurowanie źródła danych ODBC (por. rys. 12.

18 344 Robert Wrembel Rys. 12. Wybór sterownika dla źródła danych ODBC dla DB2 2. Określenie parametrów dostępu do bazy DB2 za pomocą sterownika ODBC. Niezbędnymi parametrami są: nazwa źródła danych, nazwa użytkownika bazy DB2 i jego hasło, nazwa docelowej bazy danych DB2, pełna nazwa (adres komputera z bazą docelową, numer portu komunikacyjnego z serwerem DB2 (domyślnie Skonfigurowanie usługi sieciowej Oracle. W tym celu należy umieścić odpowiednie wpisy w plikach tnsnames.ora, listener.ora i initdb2.ora, analogicznie jak dla opisanego dostępu do SQL Servera. Przykładowe wpisy te przedstawiono poniżej. Wpis w pliku initdb2.ora: HS_FDS_CONNECT_INFO = DB2 Wpis w pliku listener.ora: (SID_DESC = (SID_NAME = db2 (ORACLE_HOME = d:\oracle\ora92 (PROGRAM = hsodbc Wpis w pliku tnsnames.ora: DB2 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP(HOST = lab234-d(port = 1521 (CONNECT_DATA = (SERVICE_NAME = DB2 (HS = OK Podobnie, jak w przypadku SQL Server, z poziomu bazy danych Oracle do bazy DB2 odwołuje się za pomocą łącznika bazy danych.

19 Usługi heterogeniczne techniki integracji rozproszonych baz danych różnych producentów Połączenie DB2 Oracle Dostęp z DB2 do Oracle został zrealizowany za pomocą sterownika ODBC. W tym celu, na komputerze z serwerem DB2 zainstalowano dedykowany sterownik ODBC dla Oracle i skonfigurowano go w sposób podobny do omówionych wyżej. Dalsza procedura konfiguracyjna wymaga wykonania poniższych czynności. 1. Zdefiniowanie tzw. opakowania (ang. wrapper do bazy danych Oracle. W tym celu należy wykorzystać oprogramowanie zarządzające DB2, zwane centrum sterowania (por. rys. 13. Opakowanie jest specyficznym mechanizmem realizującym dostęp do innych źródeł danych (m.in. baz danych, plików tekstowych i dbf. Opakowanie definiuje się z wykorzystaniem albo interfejsu graficznego (por. rys.14 albo za pomocą polecenia SQL. Definiując opakowanie należy określić typ źródła danych i jego nazwę. Rys. 13. Centrum sterowania DB2

20 346 Robert Wrembel Rys. 14. Własności opakowania 2. Utworzenie tzw. definicji serwera, reprezentującego bazę Oracle w DB2. Wykorzystuje się do tego wspomniane już centrum sterowania. Okno definicji serwera pokazano na rys.15. Przycisk Wykryj umożliwia automatyczne wykrycie dostępnych zdalnych baz danych. Rys. 15. Definiowanie serwera 3. Odwzorowanie użytkownika bazy DB2 w użytkownika bazy Oracle. CREATE USER MAPPING FOR "USER" SERVER "SRV_ORA" OPTIONS ( ADD REMOTE_AUTHID 'USER_ORA', ADD REMOTE_PASSWORD 'TEST' ; 4. Utworzenie tzw. pseudonimu, reprezentującego w bazie DB2 obiekt (tabelę lub perspektywę w zdalnej bazie danych. Przykładowe okno kreatora pseudonimów przedstawiono na rysunku 16.

21 Usługi heterogeniczne techniki integracji rozproszonych baz danych różnych producentów 347 Rys. 16. Definiowanie pseudonimu 5. Dostęp do zdalnej tabeli z poziomu SQL za pomocą odwołania do utworzonego pseudonimu (np. select * from pseudonim. 5. Integracja Oracle i Sybase Adaptive Server Anywhere Dostęp pomiędzy bazą Oracle a ASA zrealizowano w obu kierunkach z wykorzystaniem sterowników ODBC, jak pokazano na rysunku Połączenie Oracle - ASA Z bazy danych Oracle do ASA dostęp będzie możliwy po zainstalowaniu na komputerze klienta dedykowanego sterownika dla ASA. Sterownik taki znajduje się na płycie instalacyjnej ASA (por. rys. 17. Rys. 17. Instalacja sterownika ODBC dla ASA Dalsza procedura konfiguracyjna przypomina tę opisaną w punkcie 3.2 i 4.1 i wymaga ona wykonania następujących czynności: 1. Skonfigurowanie źródła danych ODBC (por. rys. 18.

22 348 Robert Wrembel Rys. 18. Wybór sterownika dla źródła danych ODBC dla ASA 2. Określenie parametrów dostępu do bazy ASA za pomocą sterownika ODBC. Niezbędnymi parametrami są: nazwa źródła danych, nazwa użytkownika bazy ASA i jego hasło, nazwa docelowej bazy danych ASA, sieciowy protokół komunikacyjny (domyślnie TCP/IP, pełna nazwa (adres komputera z bazą docelową (por. rys. 19. Rys. 19. Dialog wprowadzania parametrów konfiguracyjnych połączenia ODBC 3. Skonfigurowanie usługi sieciowej Oracle. W tym celu należy umieścić odpowiednie wpisy w plikach tnsnames.ora, listener.ora i initdb2.ora, analogicznie jak dla opisanego dostępu do SQL Servera i DB2. Przykładowe wpisy te przedstawiono poniżej.

23 Usługi heterogeniczne techniki integracji rozproszonych baz danych różnych producentów 349 Wpis w pliku initasa.ora: HS_FDS_CONNECT_INFO = ASA Wpis w pliku listener.ora: (SID_DESC = (SID_NAME = ASA (ORACLE_HOME = d:\oracle\ora92 (PROGRAM = hsodbc Wpis w pliku tnsnames.ora: DB2 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP(HOST = lab234-d(port = 1521 (CONNECT_DATA = (SERVICE_NAME = ASA (HS = OK Podobnie, jak w przypadku SQL Server, z poziomu bazy danych Oracle do bazy ASA odwołuje się za pomocą łącznika bazy danych Połączenie ASA Oracle Z Adaptive Server Anywhere do Oracle dostęp jest możliwy za pomocą sterownika OBDC dla Oracle zainstalowanego na komputerze, na którym działa ASA. Procedura konfiguracyjna została opisana poniżej. 1. Z poziomu oprogramowania zarządzającego ASA, tj. Sybase Central (por. rys.20 utworzyć tzw. serwer zdalny. Reprezentuje on w ASA zdalną bazę danych. Dla serwera zdalnego należy określić: jego nazwę, typ zdalnego serwera (wybór z predefiniowanej listy, np. Oracle, DB2, SQL Server, rodzaj sterownika (ODBC lub JDBC, nazwa źródła danych OD- BC/JDBC, odwzorowanie użytkownika lokalnego w zdalnego.

24 350 Robert Wrembel Rys. 20. Główny panel zarządzania ASA 2. Utworzenie tzw. tabeli proxy (ang. proxy table, reprezentującej w ASA tabelę w zdalnej bazie danych. Za pomocą tej tabeli można również ograniczyć dostępność kolumn tabeli zdalnej. 3. Dostęp do zdalnej tabeli z poziomu SQL za pomocą odwołania do utworzonej tabeli proxy (np. select * from proxy. 6. Uwagi końcowe W ramach opisanego projektu zbudowano testowy system rozproszonych i heterogenicznych źródeł danych opartych o bazy Oracle, IBM DB2, Sybase Adaptive Server Anywhere, SQL Server, pliki tekstowe i dbf. Głównym mechanizmem dostępu do źródeł danych były sterowniki ODBC. Wyjątek stanowi integracja Oracle i SQL Server. W tym przypadku, dostęp z Oracle do SQL Server zrealizowano za pomocą oprogramowania gateway, a w drugą stronę - za pomocą sterownika OLE DB. W ramach testów udało się zbudować architekturę, w której każda baza danych mogła się łączyć z każą z pozostałych baz danych. W czasie konfigurowania i testowania architektury napotkano kilka problemów.