Usługi heterogeniczne – techniki integracji rozproszonych

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
[email protected]
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".
Usługi heterogeniczne – techniki integracji rozproszonych baz danych różnych producentów
329
1. 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 syste-
my 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, semistruk-
turalne;
• 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.
1.1. 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.
1.2. 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.
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żliwia-
ją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.
1.4. 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.
Usługi heterogeniczne – techniki integracji rozproszonych baz danych różnych producentów
FEDERATED
SERVERS
MS SQL,
ORACLE,
SYBASE,
ODBC
331
DB2
INFORMATION
INTEGRATOR
Sybase ASA
DB2
ORACLE TRANSPARENT
GATEWAY FOR MSSQL
ORACLE
MSSQL
HETEROGENOUS
SERVICES
REMOTE
SERVERS
(ORAODBC,
MSSODBC,
DB2ODBC,
ODBC)
ODBC
Linked Server
OLEDB
External Table
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
Server2000.
2.1. 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:
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.
2.2. 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ą
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.
2.3. 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).
2.3.1. 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 =
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.
2.3.2. 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.
2.3.3. 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, WrBę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)
)
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 (GATEWAYLIS 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 2.3.1).
2.3.4. 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.
2.4.1. 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 %ORACLE_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)
336
Robert Wrembel
(SERVER = DEDICATED)
)
(HS=OK)
)
2.4.2. 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).
Usługi heterogeniczne – techniki integracji rozproszonych baz danych różnych producentów
Rys. 4. Definiowanie serwera łączonego z poziomu MS Enterprise Manager
Rys. 5. Definiowanie własności serwera łączonego
337
338
Robert Wrembel
Rys. 6. Definiowanie odwzorowania użytkowników
2.4.3. 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 PRACOWNICY 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.
3.1. 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.
Usługi heterogeniczne – techniki integracji rozproszonych baz danych różnych producentów
339
3.1.1. 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
3.1.2. 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.
340
Robert Wrembel
Rys. 8. Wybór sterownika
Rys. 9. Konfigurowanie źródła danych ODBC dla plików dBase
3.1.3. Definiowanie usługi sieciowej
Usługę sieciową Oracle wskazującą na pliki dBase definiuje się w pliku %ORACLE_HOME%\network\admin\tnsnames.ora. Przykładowa definicja usługi o nazwie DBASE 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)
)
3.1.4. Konfigurowanie procesu nasłuchu
Proces nasłuchu bazy danych Oracle konfiguruje się w pliku %ORACLE_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-
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)
)
)
3.1.5. 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 3.1.2.
3.1.6. 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.
3.2. 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.
342
Robert Wrembel
Instalowanie sterowników ODBC omówiono w punkcie 3.1.1. Definiowanie źródła danych
ODBC przebiega podobnie, jak opisano w punkcie 3.1.2. 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
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 1.
4.1. 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).
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 50001).
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. 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.
Usługi heterogeniczne – techniki integracji rozproszonych baz danych różnych producentów
345
4.2. 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
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.
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 1.
5.1. 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).
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.
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.
5.2. 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 ODBC/JDBC, odwzorowanie użytkownika lokalnego w zdalnego.
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.
Usługi heterogeniczne – techniki integracji rozproszonych baz danych różnych producentów
351
6.1. Wykonywanie poleceń insert i update w DB2 wysyłanych z SQL Server
Polecenia takie nie były wykonywane w DB2 i kończyły się błędem, jak niżej.
INSERT INTO LS_DB2..USER_DB2.SAMOCHODY_DB2
VALUES (5,'FORD','T',1000)
Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'MSDASQL' reported an error.
[OLE/DB provider returned message: [IBM][CLI Driver] CLI0150E
Sterownik nie może wykonać operacji. SQLSTATE=S1C00]
Problemu nie udało się wyeliminować pomimo stosowania wielu różnych sterowników ODBC
i OLE DB.
6.2. Konwersja typu decimal przez ASA
Dostęp do atrybutów typu decimal przechowywanych w SQL Server kończy się błędem. Problem ten da się wyeliminować przez zastosowanie typu real.
6.3. Dostęp do ASA przez gateway Oracle
W ramach testów podjęto próbę zintegrowania Oracle i ASA za pomocą oprogramowania gateway dostarczonego przez Oracle. Pomimo poprawnej konfiguracji całego systemu dostęp
z Oracle kończy się błędem, jak niżej. Tego problemu nie udało się rozwiązać.
ERROR at line 1:ORA-01017: invalid username/password; logon denied[Transparent gateway for SYBASE][A07B] Illegal username and/or
password were supplied for datasource 'tg4sybs'ORA-02063: preceding 2
lines from LINK_SYBASE
6.4. Integracja Oracle i SQL Server
Z przeprowadzonych eksperymentów integracyjnych płyną dwie konkluzje dotyczące instalacji
i konfiguracji środowiska integracyjnego.
1. Po pierwsze, wpis w pliku tnsnames.ora zarówno po stronie bazy Oracle, jak i SQL Server musi posiadać parametr SERVICE_NAME, a nie SID (w standardowych konfiguracjach Oracle, parametry te można stosować zamiennie).
2. Po drugie, nazwa instancji SQL Server nie może zawierać nazwy komputera np. DCSRW\SQLSERV jest nazwą niepoprawną. W takim przypadku, nie będzie możliwe utworzenie pliku konfiguracyjnego procesu agenta o poprawnej nazwie. Musiałby się on nazywać
następująco: initDCS-RW\SQLSERVER.ora. W takim przypadku, znak "\" byłby traktowany jako element ścieżki katalogu.
Z użytkowego punktu widzenia, omówiona wyżej technologia integracyjna ma następujące
ograniczenia.
1. W przypadku poleceń SQL specyfikowanych w SQL Server, a odwołujących się do Oracle,
rozróżniane są duże i małe litery w nazwach atrybutów tabel i nazwach obiektów bazy danych.
2. W przypadku polecenia insert kierowanego do tabeli w bazie Oracle należy zawsze podawać wartości dla wszystkich atrybutów tabeli, nawet jeśli mogą one przyjmować wartości
puste.
352
Robert Wrembel
3. Rekordy wstawiane do tabeli w SQL Server z bazy Oracle blokują całą tabelę, tak, że inna
transakcja w SQL Server nie może nawet odczytać danych z tej tabeli. Zakończenie transakcji inicjowanej z bazy Oracle odblokowuje tabelę.
Literatura
[CŁMM05]
Chrzan B., Łukaszyk T., Mroczkiewicz K., Murzo A.: Integracja heterogenicznych rozproszonych baz danych. Praca dyplomowa - Wyższa Szkoła Nauk Humanistycznych i Dziennikarstwa, Poznań, 2005
[DTMS]
Dokumentacja techniczna Microsoft SQL Server2000
[Fig02]
Figas S.: Usługi heterogeniczne. Tutorial IIIV Konferencji Użytkowników i Deweloperów Oracle,
Zakopane, 2002
[HCAdmG]
Oracle Database Heterogeneous Connectivity Administrator’s Guide.10g Release 1
[MSSQL]
Materiały szkoleniowe Microsoft: Administering a Microsoft SQL Server 2000 Database,
2072ACP
[NSRefG]
Oracle Database Net Services Reference Guide. 10g Release
[NSAdmG]
Oracle Database Net Services Administrators Guide. 10g Release
[WrBę03]
Wrembel R., Bębel B.: Oracle - projektowanie rozproszonych baz danych. Wydawnictwo Helion, 2003, ISBN 83-7197-951-7
[Wr04]
Wrembel R.: Integracja danych z wykorzystaniem oprogramowania gateway. Konferencja
Hurtownie danych i Business Intelligence, Warszawa, październik 2004