techniki integracji rozproszonych baz danych różnych producentów

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 groma-

dzonych i przetwarzanych w firmie. Bazy pochodzące od różnych producentów (np. Oracle, IBM, Sybase, Microsoft) zwy-

kle 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 wszelkie-go 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 progra-mowe umożliwiające dostęp do wielu różnych źródeł danych, tj. bramki (ang. gateway) i sterow-niki 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 po-mocą 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 stano-wi 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żniej-szych 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 relacyj-nych, 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 automatyza-cję 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 Relatio-nal przy współpracy z Data Joiner pozwala na synchroniczne i asynchroniczne replikowa-nie 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. Do-stę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.


ORACLE

DB2

MSSQL

Sybase ASA

*.TXT*.DBF

ORACLE TRANSPARENT

GATEWAY FOR MSSQL

OLEDB

Linked Server

HETEROGENOUS

SERVICES

ODBC

REMOTE

SERVERS

(ORAODBC,

MSSODBC,

DB2ODBC,

ODBC)

DB2

INFORMATION

INTEGRATOR

FEDERATED

SERVERS

MS SQL,

ORACLE,

SYBASE,

ODBC

ODBC

MS JET

Linked Server

External Table

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 da-nych 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 sys-temu). 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ą sie-ciową.

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 sterow-nika OLE DB po stronie SQL Server i procesu nasłuchu, po stronie Oracle (por. [NSRefG, NSAd-mG, 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 se-rver).

2. Przekazanie żądania (po jego translacji) przez sterownik OLE DB do bazy Oracle reprezen-towanej 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ą


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ę podkata-log 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 init-tg4msql.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ą zawar-tość 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. Para-metr 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 uru-chamiają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 znajdu-je 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łącze-nia 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 siecio-wych 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ę tnsna-mes.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) )


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 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 de-finicji 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ą łączni-ki 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 tn-snames.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 %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)

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 zdefinio-wanie 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 na-zwa. 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 pre-definiowana 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).


Rys. 4. Definiowanie serwera łączonego z poziomu MS Enterprise Manager

Rys. 5. Definiowanie własności serwera łączonego

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 PRA-COWNICY znajdującej się w schemacie użytkownika SCOTT. LAB10G jest nazwą serwera łączo-nego.

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ć wi-doczne 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 dBa-se 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 heterogenicz-nych Oracle.

5. Skonfigurować agenta usług heterogenicznych.

6. Utworzyć łącznik bazy danych z wykorzystaniem zdefiniowanej w kroku 3 nazwy usługi sieciowej.


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 admini-stracyjne. 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 %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ła-my 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 %ORAC-

LE_HOME%\network\admin\listener.ora. Przykładowe parametry nasłuchu dla zdefi-niowanej 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-


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 ka-talogu %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 spo-só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 wska-zują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. Ko-lejną ważną cechą omawianej technologii integracyjnej jest brak obsługi przetwarzania transak-cyjnego.

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ść wskaza-nia 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 parame-try ź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 po-niż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


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 wyko-rzystujący usługę ACCESS (plik tnsnames.ora), która z kolei poprzez proces nasłuchu i agen-ta 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 ste-rownikó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 wykona-nia 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 opisane-go 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.


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 skonfigu-rowano 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 opako-wanie 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 perspekty-wę) w zdalnej bazie danych. Przykładowe okno kreatora pseudonimów przedstawiono na rysunku 16.


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 ste-rownikó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 wy-konania 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ęd-nymi 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.


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 OD-BC/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 ba-zie danych. Za pomocą tej tabeli można również ograniczyć dostępność kolumn tabeli zdal-nej.

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 Se-rver 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.


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. Pro-blem 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 ga-teway 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 de-

nied[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 Se-rver musi posiadać parametr SERVICE_NAME, a nie SID (w standardowych konfigura-cjach Oracle, parametry te można stosować zamiennie).

2. Po drugie, nazwa instancji SQL Server nie może zawierać nazwy komputera np. DCS-RW\SQLSERV jest nazwą niepoprawną. W takim przypadku, nie będzie możliwe utworze-nie 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 trak-towany 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 da-nych.

2. W przypadku polecenia insert kierowanego do tabeli w bazie Oracle należy zawsze po-dawać 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 transak-cji inicjowanej z bazy Oracle odblokowuje tabelę.

Literatura

[CŁMM05] Chrzan B., Łukaszyk T., Mroczkiewicz K., Murzo A.: Integracja heterogenicznych rozproszo-

nych baz danych. Praca dyplomowa - Wyższa Szkoła Nauk Humanistycznych i Dziennikar-

stwa, 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 He-

lion, 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

techniki integracji rozproszonych baz danych różnych producentów

Documents

Transcript of techniki integracji rozproszonych baz danych różnych producentów