Architektury i technologie integracji danychtpd.cs.put.poznan.pl/.../ArchitekturyiTechnologieIntegracjiDanych... · również ręcznie odłączyć się od bazy danych poleceniem disconnect

Strona 1 z 51

Architektury i technologie

integracji danych

Materiały laboratoryjne

Edycja 2018/19

Wersja dla konfiguracji „Wirtualnego Laboratorium”

Bartosz Bębel

Politechnika Poznańska, Instytut Informatyki

Strona 2 z 51

Wprowadzenie do ć wićzenia

Niniejsze ćwiczenie ma za zadanie zademonstrować słuchaczowi szereg technik, umożliwiających

utworzenie środowiska integrującego dane zarówno heterogeniczne (różne formaty danych,

oprogramowanie różnych producentów) jak i dane homogeniczne. W ćwiczeniu zamodelujemy

działanie systemu informatycznego wyższej Wirtualnej Uczelni. Uczelnia składa się z następujących

jednostek organizacyjnych:

Dziekanat – przechowuje dane osobowe studentów oraz dane o ocenach i zaliczeniach,

Dział Stypendiów – przechowuje informacje o przyznanych studentom świadczeniach,

Dział Zarządzania Akademikami – przechowuje dane o akademikach i zakwaterowanych w

nich studentach,

Studium Języków Obcych – przechowuje dane o zdobytych przez studentów ocenach i

zaliczeniach z lektoratów,

Dział Kształcenia – jednostka zajmująca się sprawozdawczością.

Naszym celem będzie umożliwienie pracownikom Działu Kształcenia przygotowania szeregu

raportów, pokazujących różne aspekty działania Wirtualnej Uczelni.

Uwaga! Przy kopiowaniu umieszczonych w dokumencie zawartości plików konfiguracyjnych zwróć uwagę na możliwość wystąpienia niezgodności w kodowaniu znaków końca linii pomiędzy tekstem w dokumencie a tekstem w systemie Linux. Może to powodować błędną interpretację parametrów konfiguracyjnych. Dlatego w tekście skopiowanym z dokumentu do plików w systemie Linux usuń znaki końców linii i wstaw je ponownie.

Strona 3 z 51

Środowisko ćwiczeniowe

W tym ćwiczeniu będziesz pracował/a na komputerze symulującym działanie serwera

bazodanowego. Serwer będzie działał pod kontrolą systemu operacyjnego CentOS 6 (jest to jedna z

dystrybucji systemu Linux). System operacyjny został przygotowany do instalacji systemów

zarządzania bazami danych różnych producentów (m.in. Oracle, IBM). W środowisku sieciowym nasz

serwer będzie identyfikowany pod nazwą integracja_mw.

1. Po pomyślnym uruchomieniu serwera powinien zostać wyświetlony ekran logowania.

2. Zaloguj się do systemu operacyjnego jako użytkownik oracle z hasłem oracle. Naciśnij myszą

na pozycję Oracle owner na liście użytkowników, podaj hasło i naciśnij przycisk Zaloguj.

Strona 4 z 51

3. Użytkownik oracle został tak skonfigurowany, że po zalogowaniu automatycznie

uruchamiany jest dla niego zarządca okien GNOME (w systemie Linux dostępnych jest kilka

różnych aplikacji – zarządców okien, m.in. KDE, X).

Część operacji administracyjnych będziemy wykonywać posługując się głównie myszką,

jednak czasami będziemy musieli użyć tekstowej konsoli, tzw. terminala tekstowego.

Uruchomienie terminala można wykonać klikając myszą na pozycję Programy w menu

systemowym, następnie wybierając grupę Narzędzia systemowe i skrót Terminal.

Alternatywnie można kliknąć na ikonę na górnym pasku zarządcy okien. Terminal

zostanie uruchomiony w osobnym oknie.

Otwórz terminal, sprawdź, w jakim katalogu aktualnie się znajdujesz (polecenie pwd) a

następnie wyświetl listę plików, jakie znajdują się w bieżącym katalogu (polecenie ls -l).

Zamknij terminal (polecenie exit lub kliknięcie na przycisk x w prawym górnym rogu okna).

Strona 5 z 51

Ć wićzenie 1.

Celem niniejszego ćwiczenia jest utworzenie heterogenicznego środowiska baz danych.

Wykorzystamy do tego celu zainstalowane już na komputerze serwery baz danych IBM DB2 Oracle.

Serwer DB2 zawiera bazę danych FINANSE, z której korzysta Dział Stypendiów naszej Wirtualnej

Uczelni. W bazie FINANSE znajdują się dwie tabele:

RODZAJE_SWIADCZEN – przechowuje informacje o rodzajach przyznawanych studentom

świadczeń,

SWIADCZENIA – przechowuje informacje o świadczeniach przyznanych studentom.

Z kolei serwer bazy danych Oracle jest wykorzystywany przez Dział Kształcenia Wirtualnej Uczelni.

Naszym zadaniem będzie umożliwienie odczytu danych z serwera bazy danych DB2, wykorzystywanej

przez Dział Stypendiów, przez pracowników Działu Kształcenia, będących użytkownikami bazy danych

Oracle.

Wprowadzenie do środowiska DB2

Na początek spróbujesz przyłączyć się do bazy DB2, obejrzeć jej zawartość i wykonać kilka

przykładowych operacji.

1. Jeśli tego dotąd nie zrobiłaś/eś, uruchom serwer a następnie zaloguj się jako użytkownik

oracle.

2. Uruchom nowy terminal, następnie w terminalu przyłącz się jako użytkownik db2inst1 z

hasłem db2. Użyj polecenia su – db2inst1. Po pomyślnym przyłączeniu się jako

użytkownik db2inst1, nazwa tego użytkownika powinna zostać wyświetlona w znaku zachęty

(ang. prompt).

3. Aby móc przyłączyć się do bazy danych IBM DB2, konieczne jest uruchomienie Menedżera

Bazy Danych DB2. Uruchom menedżera bazy danych, wykonując polecenie db2start.

(możesz otrzymać komunikat: "Menedżer baz danych jest już aktywny", oznacza to, że

narzędzie już działa). Następnie uruchom procesor wiersza komend dla DB2 poleceniem db2.

Po uruchomieniu procesora wiersza znak zachęty powinien zmienić się na db2 =>.

Strona 6 z 51

4. Sprawdź, jakie bazy danych zostały zdefiniowane w DB2. W tym celu w procesorze komend

dla DB2 wykonaj polecenie list db directory.

Strona 7 z 51

5. Baza danych, w której znajdują się interesujące nas dane, nosi nazwę FINANSE. Przyłącz się

do bazy FINANSE wykonując polecenie connect to finanse.

db2 => connect to finanse

Informacje o połączeniach bazy danych

Serwer baz danych = DB2/LINUX 10.5.0

ID autoryzowanego użytkownika SQL = DB2INST1

Alias lokalnej bazy danych = FINANSE

6. Odczytaj nazwy tabel, jakie istnieją w bazie danych FINANSE. W tym celu wykonaj polecenie

list tables.

db2 => list tables

Tabela/Widok Schemat Typ Czas utworzenia

------------------------------- --------------- ----- -----------------------

---

RODZAJE_SWIADCZEN DB2INST1 T 2013-07-05-

12.37.19.598124

SWIADCZENIA DB2INST1 T 2013-07-04-

14.39.22.529645

Wybrano rekordów: 2.

7. Zapoznaj się ze strukturą tabel w bazie danych FINANSE. Polecenie wyświetlające schemat

tabeli to describe table <nazwa_tabeli>.

db2 => describe table rodzaje_swiadczen

Schemat Długość

Nazwa kolumny typu danych Nazwa typu danych kolumny

Skala NULL

------------------------------- --------- ------------------- ---------- ----

- ------

SYMBOL SYSIBM VARCHAR 2

0 Nie

NAZWA SYSIBM VARCHAR 50

0 Tak


db2 => describe table swiadczenia

...

Strona 8 z 51

8. Wyświetl zawartość tabel z bazy danych FINANSE, wykonując odpowiednie polecenia języka

SQL.

db2 => SELECT * FROM rodzaje_swiadczen

SYMBOL NAZWA

------ --------------------------------------------------

SN stypendium za wyniki w nauce

SS stypendium socjalne

SP stypendium sportowe


db2 => SELECT * FROM swiadczenia

...

9. Zakończ pracę z menedżerem bazy danych DB2 poleceniem quit. Zamknięcie menedżera

bazy danych DB2 automatycznie odłącza użytkownika od przyłączonej bazy danych (możesz

również ręcznie odłączyć się od bazy danych poleceniem disconnect <baza danych>,

np. disconnect finanse). Zamknij również sesję użytkownika db2inst1 (polecenie

exit) i terminal (kolejne polecenie exit).

Strona 9 z 51

Konfiguracja połączenia Oracle – DB2

Przystąpimy teraz do skonfigurowania połączenia między bazą danych Oracle a bazą IBM DB2.

Połączenie umożliwi nam wymianę danych między połączonymi bazami. Zasymuluje to sytuację

pobrania danych przez Dział Kształcenia (baza danych Oracle) z bazy Działu Stypendiów (baza danych

DB2). Połączenie będzie realizowane przez dedykowane oprogramowanie o nazwie brama

(ang. gateway).

1. Proces konfiguracji środowiska rozpoczniemy od zainstalowania oprogramowania Oracle

Database Gateway, pozwalającego na dostęp z SZBD Oracle do informacji w bazach danych

innych producentów. Wersja instalacyjna tego oprogramowania została już pobrana ze

strony producenta (adres: http://oracle.com) i umieszczona w odpowiednim katalogu

serwera.

2. Otwórz terminal jako użytkownik oracle. Następnie przejdź do katalogu

WersjeInstalacyjne/gateways (polecenie cd WersjeInstalacyjne/gateways) i

uruchom plik runInstaller (polecenie ./runInstaller).

Strona 10 z 51

3. Na ekranie powitalnym instalatora naciśnij przycisk Next.

4. Pozostaw niezmienione opcje określające nazwę i lokalizację katalogu domowego

oprogramowania Oracle. Naciśnij przycisk Next.

Strona 11 z 51

5. Instalator dokonuje teraz weryfikacji zgodności zainstalowanego już oprogramowania Oracle

z oprogramowaniem, które chcemy zainstalować. Nie powinno być żadnych niezgodności

(Status: Succeeded). Naciśnij przycisk Next.

6. Na ekranie wyboru oprogramowania zaznacz pozycję Oracle Database Gateway for DRDA

11.2.0.3.0 i naciśnij przycisk Next.

Strona 12 z 51

7. Zdefiniuj parametry serwera DB2, do którego dostęp będzie umożliwiało instalowane

oprogramowanie:

lokalizacja serwera DB2: integracja_mw (czyli nasz serwer)

port procesu nasłuchu serwera DB2: 50000

nazwa bazy danych DB2: FINANSE

typ serwera DB2: LUW

Następnie naciśnij przycisk Next.

Strona 13 z 51

8. Sprawdź ustawienia procesu instalacji, następnie rozpocznij instalowanie oprogramowania

naciskając przycisk Install. Instalacja potrwa kilka minut.

Strona 14 z 51

9. Teraz konieczne jest ręczne uruchomienie skryptu, przeprowadzającego dodatkowe

czynności konfiguracyjne instalowanego oprogramowania. W tym celu uruchom nowy

terminal i przyłącz się w nim jako użytkownik root z hasłem root. Użyj do tego celu polecenia

su – root. Następnie przejdź do katalogu /u01/app/oracle/product/11.2.0/dbhome_1/

(polecenie cd …) i uruchom plik root.sh. Przy odpowiedzi na wszystkie pytania, jakie zostaną

zadane podczas uruchomienia skryptu, udziel odpowiedzi domyślnych (naciśnij klawisz

Enter). Po zakończeniu działania skryptu zamknij terminal (dwukrotnie polecenie exit) a w

oknie dialogowym naciśnij przycisk OK.

10. Instalacja zostaje zakończona i oprogramowanie jest gotowe do działania. Naciśnij przycisk

Exit i potwierdź chęć zamknięcia instalatora przyciskiem Yes. Terminal pozostaw aktywny –

wykorzystamy go do skonfigurowania zainstalowanego właśnie oprogramowania Oracle

Gateway.

Strona 15 z 51

11. Przystąpimy teraz do skonfigurowania poszczególnych elementów serwera bazodanowego, z

którego korzysta Dział Kształcenia. Na początek uruchomimy serwer bazy danych Oracle oraz

proces nasłuchu Oracle Listener (odpowiada za obsługę żądań klientów przyłączających się do

bazy danych). W tym celu w terminalu, będąc zalogowanym jako użytkownik oracle:

aby uruchomić proces nasłuchu Oracle Listener wykonaj lsnrctl start

aby uruchomić serwer bazy danych w programie SQL*Plus uwierzytelnij się jako

użytkownik administracyjny SZBD Oracle poleceniem sqlplus "/as sysdba",

po pomyślnym uwierzytelnieniu wykonaj polecenie startup,

po uruchomieniu serwera zamknij program SQL*Plus poleceniem exit.

Strona 16 z 51

12. Pozostań w terminalu. Przejdź do katalogu

/u01/app/oracle/product/11.2.0/dbhome_1/dg4db2/admin/ (możesz posłużyć się zmienną

środowiskową ORACLE_HOME, w której zapisana jest ścieżka do katalogu oprogramowania

Oracle, wykonując polecenie cd $ORACLE_HOME/dg4db2/admin/).

13. Otwórz plik initdg4db2.ora. (możesz do tego celu użyć edytora systemowego gedit i

polecenia gedit initdg4db2.ora), przechowujący parametry konfiguracyjne bramy

(ang. gateway), umożliwiającej dostęp z serwera Oracle do serwera DB2. Sprawdź zawartość

pliku, zwróć uwagę na wartość parametru HS_FDS_CONNECT_INFO – zawiera on parametry

docelowego serwera DB2 oraz nazwę bazy danych, które zostały podane podczas instalacji

oprogramowania Oracle Gateway. Nie zmieniaj zawartości tego pliku! Zamknij edytor.

14. Aby móc wykonywać dostęp z serwera Oracle do serwera DB2, procesu nasłuchu Oracle

Listener musi zostać odpowiednio skonfigurowany. Przejdź do katalogu

$ORACLE_HOME/network/admin i otwórz do edycji plik listener.ora. Dodaj na końcu pliku

następujący wpis:

SID_LIST_LISTENER=

(SID_LIST=

(SID_DESC=

(SID_NAME=dg4db2)

(ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1)

(PROGRAM=dg4db2)

)

)

15. Zapisz plik i zamknij edytor. Następnie, aby wprowadzone w poprzednim punkcie zmiany

weszły w życie, dokonaj restartu procesu nasłuchu bazy danych Oracle wykonując polecenia

lsnrctl stop a następnie lsnrctl start. Poleceniem lsnrctl status

możesz wyświetlić stan procesu nasłuchu. Zwróć uwagę na komunikat Instancja "dg4db2",

Strona 17 z 51

stan …. Oznacza on, że proces nasłuchu został poprawnie skonfigurowany do dostępu do

zewnętrznej bazy danych przez bramę.

16. Kolejny krok to zdefiniowanie nazwy, pod którą użytkownik bazy danych Oracle będzie

odwoływał się do zdalnej bazy DB2. W tym celu otwórz do edycji plik tnsnames.ora (znajduje

się w tym samym katalogu co plik listener.ora) a następnie dodaj na końcu pliku wpis:

db2finanse =

(DESCRIPTION=

(ADDRESS=(PROTOCOL=tcp)(HOST=integracja_mw)(PORT=1521))

(CONNECT_DATA=(SID=dg4db2))

(HS=OK)

)

Powyższy wpis określa, że adresując obiekty w bazie danych FINANSE serwera DB2

użytkownik serwera Oracle będzie posługiwał się nazwą db2finanse. Zapisz zmiany i zakończ

edycję pliku.

Strona 18 z 51

17. Możesz przetestować poprawność dokonanego w poprzednim punkcie wpisu, wykonując

polecenie tnsping db2finanse. Jeśli otrzymałaś/eś komunikat "OK", oznacza to sukces

w nawiązaniu kontaktu ze zdalną (w stosunku do serwera bazy Oracle) bazą danych DB2.

Następnie zamknij terminal.

Strona 19 z 51

Testowanie komunikacji Oracle – DB2

Przetestujemy teraz, czy wykonane dotąd czynności konfiguracyjne odniosły skutek – czy możemy z

Działu Stypendiów (baza DB2) pobrać dane do Działu Kształcenia (baza Oracle).

1. Uruchom narzędzie Oracle SQL Developer (ikona na górnym pasku zarządcy okien). Narzędzie

to służy do wygodnej edycji i wysyłania do bazy danych Oracle poleceń języka SQL. Narzędzie

zostało już wstępnie skonfigurowane, tak abyś mogła/mógł przyłączyć się do bazy danych

Oracle o nazwie baza01. Jest to baza, w której Dział Kształcenia będzie gromadził dane,

pobrane ze źródeł zewnętrznych, celem ich późniejszej analizy. W oknie Connections rozwiń

drzewo rozpoczynające się od węzła baza01 (kliknij na krzyżyk). W wyświetlonym oknie

Connection Information podaj parametry użytkownika bazy danych Oracle, który będzie

używany do integracji z serwerem DB2:

nazwa (pole Username): integracja

hasło (pole Password): oracle

Następnie naciśnij przycisk OK.

Zakładamy, że z konta użytkownika integracja będą korzystali pracownicy Działu Kształcenia

w procesie przygotowywania zbiorczych raportów, pokazujących różne aspekty działania

Wirtualnej Uczelni.

Strona 20 z 51

2. Użytkownik integracja na razie nie posiada żadnych obiektów, możesz to sprawdzić

poleceniem

SELECT * FROM user_objects; (wpisz polecenie do okna Worksheet, wykonaj je

naciskając klawisze Ctrl+Enter lub przycisk Run Statement w pasku narzędziowym).

3. Do komunikacji ze zdalnym serwerem (w naszym przypadku będzie to serwer bazy danych

DB2 Działu Stypendiów) konieczne jest utworzenie tzw. łącza bazodanowego. Do utworzenia

łącza wykorzystujemy następujące polecenie:

CREATE DATABASE LINK <nazwa łącza>

CONNECT TO <nazwa użytkownika w zdalnej bazie danych>

IDENTIFIED BY <hasło użytkownika w zdalnej bazie danych>

USING '<nazwa identyfikująca zdalną bazę danych>';

W naszym przypadku parametry łącza są następujące:

nazwa łącza: db2finanse,

nazwa użytkownika w bazie danych DB2: db2inst1,

hasło użytkownika w bazie danych DB2: db2,

wskazanie zdalnej bazy danych: db2finanse (przypomnijmy: ta nazwa została

zdefiniowana przez nas w pliku tnsnames.ora).

Łącze wykorzystuje do komunikacji z serwerem DB2 wcześniej zainstalowane przez nas

oprogramowanie Oracle Gateways.

4. Sprawdź działanie utworzonego łącza bazodanowego. Spróbuj odczytać dane z tabel

umieszczonych w bazie danych DB2 wykonując w Oracle SQL Developer następujące

polecenia:

SELECT * FROM rodzaje_swiadczen@db2finanse;

SELECT * FROM swiadczenia@db2finanse;

5. Utwórz w schemacie użytkownika integracja w bazie danych Oracle dwie perspektywy, które

ułatwią korzystanie z danych pobieranych z serwera DB2 (użytkownik bazy Oracle będzie

„widział” zdalne dane w taki sam sposób jak dane lokalne):

perspektywa RODZAJE_SWIADCZEN_V, która będzie udostępniać wszystkie dane z tabeli

RODZAJE_SWIADCZEN z bazy DB2,

perspektywa SWIADCZENIA_V, która będzie udostępniać połączone dane z tabel

RODZAJE_SWIADCZEN i SWIADCZENIA, umieszczonych w bazie danych DB2 (zbuduj

warunek połączeniowy wykorzystując atrybuty: rodzaj_swiadczenia z tabeli

SWIADCZENIA i symbol z tabeli RODZAJE_SWIADCZEN).

Następnie sprawdź działanie obu perspektyw.

Strona 21 z 51

CREATE VIEW rodzaje_swiadczen_v AS

SELECT * FROM rodzaje_swiadczen@db2finanse;

SELECT * FROM rodzaje_swiadczen_v;

SYMBOL NAZWA

------ ------------------------------




CREATE VIEW swiadczenia_v AS

…

SELECT student, semestr, nazwa, kwota, data_przyznania

FROM swiadczenia_v ORDER BY student;

STUDENT SEMESTR NAZWA KWOTA

DATA_PRZYZNANIA

------ -------------------- ---------------------------- ----- --------------

--

365 2001/02 zimowy stypendium za wyniki w nauce 750 01/10/01

365 2001/02 letni stypendium za wyniki w nauce 750 02/03/01



366 2000/01 zimowy stypendium socjalne 196 00/10/01





367 2001/02 zimowy stypendium socjalne 153 01/10/01

...

6. Spróbuj za pomocą perspektywy RODZAJE_SWIADCZEN_V dodać nowy rodzaj świadczenia o

nazwie „stypendium ministerialne” i symbolu „SM”.

INSERT INTO rodzaje_swiadczen_v(symbol, nazwa)

VALUES ('SM', 'stypendium ministerialne');


SYMBOL NAZWA

------ ----------------------------




SM stypendium ministerialne

7. Otwórz nowy terminal i przyłącz się jako użytkownik db2inst1. Następnie przyłącz się do bazy

danych FINANSE serwera DB2 i sprawdź zawartość tabeli RODZAJE_SWIADCZEN. Czy wynik

zapytania zawiera dodany w poprzednim punkcie (w bazie danych Oracle) rodzaj

świadczenia?


???

Wybrano rekordów: ???.

Strona 22 z 51

8. Wróć do Oracle SQL Developer i zatwierdź bieżącą transakcję poleceniem commit.

Ponownie sprawdź zawartość tabeli RODZAJE_SWIADCZEN w bazie FINANSE serwera DB2.


SYMBOL NAZWA

------ --------------------------------------------------






Punkty dodatkowe (9. – 14.) – do wykonania jeśli pozostał jeszcze czas.

9. Tym razem dodaj nowy rodzaj świadczenia o nazwie „dodatek do DS” i symbolu „DS” do

tabeli RODZAJE_SWIADCZEN w bazie FINANSE serwera DB2. Sprawdź w Oracle SQL Developer

jaka jest bieżąca zawartość perspektywy RODZAJE_SWIADCZEN_V.

db2 => INSERT INTO rodzaje_swiadczen VALUES('DS','dodatek do DS')

DB20000I Wykonanie komendy SQL zakończyło się pomyślnie.

Oracle SQL Developer:


Widzisz różnicę w obsłudze transakcji pomiędzy Oracle i DB2?

10. Sprawdź tryb zatwierdzania transakcji w DB2. W tym celu wykonaj polecenie LIST

COMMAND OPTIONS.

db2 => LIST COMMAND OPTIONS

Ustawienia opcji procesora wiersza komend

Czas oczek. procesu od strony serwera (s) (DB2BQTIME) = 1

Liczba prób połączeń od strony serwera (DB2BQTRY) = 60

Czas oczekiwania w kolejce żądań (s) (DB2RQTIME) = 5

Czas oczekiwania w kol. wejściowej (s) (DB2IQTIME) = 5

Opcje komend (DB2OPTIONS) =

Opcja Opis Bieżące ustaw.

------ ---------------------------------------- ---------------

-a Wyświetlaj obszar komunikacyjny SQL OFF

-b Wykonaj automatyczne wiązanie ON

-c Zatwierdzaj automatycznie ON

-d Pobieraj i wyświetlaj deklaracje XML OFF

...

Zwróć uwagę na pozycję Zatwierdzaj automatycznie.

Strona 23 z 51

11. Wyłącz w DB2 automatyczne zatwierdzanie transakcji poleceniem UPDATE COMMAND

OPTIONS USING c OFF, sprawdź ponownie tryb zatwierdzania transakcji.

db2 => UPDATE COMMAND OPTIONS USING c OFF

DB20000I Wykonanie komendy UPDATE COMMAND OPTIONS zakończyło się

pomyślnie.

db2 => LIST COMMAND OPTIONS

Ustawienia opcji procesora wiersza komend

Czas oczek. procesu od strony serwera (s) (DB2BQTIME) = 1

Liczba prób połączeń od strony serwera (DB2BQTRY) = 60

Czas oczekiwania w kolejce żądań (s) (DB2RQTIME) = 5

Czas oczekiwania w kol. wejściowej (s) (DB2IQTIME) = 5

Opcje komend (DB2OPTIONS) =

Opcja Opis Bieżące ustaw.

------ ---------------------------------------- ---------------

-a Wyświetlaj obszar komunikacyjny SQL OFF

-b Wykonaj automatyczne wiązanie ON

-c Zatwierdzaj automatycznie OFF

-d Pobieraj i wyświetlaj deklaracje XML OFF

...

12. W DB2 usuń dodany uprzednio rodzaj świadczenia o symbolu „DS”. Sprawdź w Oracle SQL

Developer jaka jest bieżąca zawartość perspektywy RODZAJE_SWIADCZEN_V.

db2 => DELETE rodzaje_swiadczen WHERE symbol = 'DS'

DB20000I Wykonanie komendy SQL zakończyło się pomyślnie.


SYMBOL NAZWA

------ --------------------------------------------------






Oracle SQL Developer:


13. Zatwierdź w DB2 bieżącą transakcję poleceniem commit. W Oracle SQL Developer sprawdź

ponownie zawartość perspektywy RODZAJE_SWIADCZEN_V.

14. Zadanie samodzielne. Dodaj do perspektywy RODZAJE_SWIADCZEN_V nowy rodzaj

świadczenia, pozostaw aktywną (niezatwierdzoną) transakcję. Następnie dodaj w DB2 do

tabeli RODZAJE_SWIADCZEN ten sam rodzaj świadczenia. Zatwierdź transakcję w Oracle SQL

Developer. Co obserwujesz w DB2? Wykonaj analogiczną operację, tym razem jako pierwszy

dodaj nowy rodzaj świadczenia do DB2.

Koniec punktów dodatkowych

Strona 24 z 51

15. Po zakończeniu ćwiczenia odłącz się od bazy danych DB2 i zamknij terminal. Następnie

zamknij narzędzie Oracle SQL Developer.

Strona 25 z 51

Ć wićzenie 2.

W bieżącym ćwiczeniu spróbujemy połączyć system zarządzania bazą danych Oracle ze źródłem

danych za pomocą interfejsu ODBC (ang. Open Database Connectivity). Interfejs ODBC, z racji

zaimplementowania dla niego wielu sterowników do różnorakich typów źródeł danych, jest często

wykorzystywany przy dostępie do danych w niewspieranych już, spadkowych formatach. W naszym

środowisku integracji wykorzystamy ten interfejs do dostępu do danych udostępnianych przez

serwer bazy danych MySQL. Przechowywane tam są dane systemu, wykorzystywanego przez Dział

Zarządzania Akademikami naszej Wirtualnej Uczelni. Baza danych nosi nazwę AKADEMIKI, zawiera

dwie tabele:

DOMY_STUDENCKIE – przechowuje informacje o akademikach, w których mieszkają studenci

wirtualnej uczelni,

PRZYZNANE_MIEJSCA – zawiera dane o miejscach w akademikach, przyznanych studentom w

poszczególnych semestrach akademickich.

Naszym zadaniem będzie umożliwienie dostępu z serwera bazy danych Oracle (Dział Kształcenia) do

danych z bazy AKADEMIKI serwera MySQL.

Konfiguracja źródła danych ODBC

W bieżącym punkcie skonfigurujemy nasz system, aby móc wykonywać dostęp do danych w bazie

AKADEMIKI serwera MySQL przy pomocy interfejsu ODBC.

1. Uruchom terminal jako użytkownik oracle. W terminalu wykonaj polecenie odbcinst -j,

które pokaże aktualny stan interfejsu ODBC w systemie.

Strona 26 z 51

Znaczenie poszczególnych pozycji jest następujące:

DRIVERS – lokalizacja pliku przechowującego definicje zainstalowanych w systemie

sterowników dla różnych typów źródeł danych,

SYSTEM DATA SOURCES – lokalizacja pliku przechowującego definicje systemowych

źródeł danych (źródeł dostępnych dla wszystkich użytkowników systemu),

FILE DATA SOURCES – lokalizacja pliku przechowującego definicje źródeł danych

dostępnych dla wszystkich użytkowników systemu,

USER DATA SOURCES – lokalizacja pliku przechowującego definicje prywatnych źródeł

danych (źródeł dostępnych tylko dla konkretnego użytkownika, w tym wypadku

użytkownika oracle),

pozostałe wpisy określają dodatkowe parametry ODBC.

2. Sprawdź, jakie sterowniki i źródła danych są aktualnie zdefiniowane w systemie (obejrzyj

zawartość plików, wskazywanych przez wynik działania polecenia odbcinst).

3. Zainstalujemy teraz sterownik ODBC dla bazy danych MySQL. W tym celu w terminalu

przyłącz się jako użytkownik root z hasłem root (polecenie su – root). Następnie przejdź

do katalogu /home/oracle/WersjeInstalacyjne. Umieszczono tam plik mysql-connector-odbc-

5.1.12-1.el6.i686.rpm z oprogramowaniem instalującym sterownik ODBC umożliwiający

dostęp do serwera MySQL. Proces instalacji uruchamia polecenie rpm –ihv mysql-

connector-odbc-5.1.12-1.el6.i686.rpm.

Po chwili proces instalacji powinien ulec zakończeniu (jednym z efektów instalacji jest

umieszczenie w katalogu /usr/lib pliku sterownika o nazwie libmyodbc5.so, sprawdź, czy taki

plik został utworzony). Zakończ sesję użytkownika root (polecenie exit), pozostań

zalogowanym w terminalu jako użytkownik oracle.

Strona 27 z 51

4. Zdefiniujemy teraz źródło danych dla użytkownika oracle, pozwalające na dostęp do danych

serwera MySQL. W tym celu otwórz plik .odbc.ini z katalogu /home/oracle (lub utwórz nowy

jeśli taki plik jeszcze nie istnieje) poleceniem gedit /home/oracle/.odbc.ini (zwróć

uwagę na kropkę przed odbc). Parametry nowego źródła danych ODBC będą następujące:

nazwa źródła: mysql

lokalizacja pliku sterownika (Driver): /usr/lib/libmyodbc5.so

opis (Description): Serwer MySQL

lokalizacja serwera (Server): integracja_mw

nazwa bazy danych (Database): Akademiki

lokalizacja gniazda dostępu do serwera (Socket): /var/lib/mysql/mysql.sock

Zawartość pliku .odbc.ini przedstawiono poniżej.

[mysql]

Driver=/usr/lib/libmyodbc5.so

Description=Serwer MySQL

Server=integracja_mw

Database=akademiki

Socket=/var/lib/mysql/mysql.sock

5. Przetestuj działanie definicji źródła mysql. W tym celu uruchom program isql, przy pomocy

którego wykonasz zapytanie do plikowego źródła danych (program jest instalowany razem z

zarządcą interfejsu ODBC). Polecenie uruchamiające program to isql –v <nazwa

źrodła> <nazwa użytkownika bd> <hasło>, gdzie: <nazwa źródła> – nazwa

zdefiniowana w pliku .odbc.ini (w naszym przypadku: mysql), <nazwa użytkownika bd> to

nazwa użytkownika w bazie danych, a <hasło> to hasło użytkownika w bazie danych. W bazie

AKADEMIKI serwera MySQL istnieje użytkownik akademiki_u z hasłem akademiki_u, mający

dostęp do danych. Użyj tego użytkownika przy podłączeniu się do uprzednio zdefiniowane

źródła danych. Następnie wykonaj zapytania do dwóch tabel z bazy danych AKADEMIKI

(DOMY_STUDENCKIE i PRZYZNANE_MIEJSCA). Zamknij narzędzie poleceniem quit.

Strona 28 z 51

Jeśli otrzymałaś/eś wyniki zapytań, oznacza to, że interfejs ODBC to bazy danych MySQL został

poprawnie skonfigurowany. Zamknij narzędzie poleceniem quit.

Konfiguracja oprogramowania Oracle Gateway dla ODBC

Dokonamy teraz konfiguracji serwera Oracle, aby móc w bazie danych Oracle skorzystać ze

zdefiniowanego wcześniej źródła danych ODBC przy dostępie do serwera MySQL.

1. Jako użytkownik oracle zainstaluj oprogramowanie Oracle Gateway dla ODBC. Powtórz

proces instalacji, opisany w części „Konfiguracja połączenia Oracle – DB2”, tym razem

wybierając produkt Oracle Database Gateway for ODBC 11.2.0.3.0.

Strona 29 z 51

2. W terminalu, gdzie jesteś zalogowana/y jako użytkownik oracle, przejdź do katalogu

$ORACLE_HOME/hs/admin. Jest to katalog, w którym znajdują się pliki konfiguracyjne Oracle

Gateway for ODBC. Następnie otwórz do edycji nowy plik o nazwie initmysqlodbc.ora (użyj

polecenia gedit initmysqlodbc.ora). Plik ten posłuży nam do skonfigurowania

połączenia bazy danych Oracle z bazą MySQL za pomocą interfejsu ODBC.

3. W pliku initmysqlodbc.ora wpisz następujące pozycje:

HS_FDS_CONNECT_INFO = mysql

HS_FDS_TRACE_LEVEL = off

HS_FDS_SHAREABLE_NAME = /usr/lib/libmyodbc5.so

HS_LANGUAGE=polish_poland.ee8iso8859P2

set ODBCINI=/home/oracle/.odbc.ini

set

LD_LIBRARY_PATH=/usr/lib:/u01/app/oracle/product/11.2.0/dbhome_1/lib

Znaczenie poszczególnych pozycji jest następujące:

HS_FDS_CONNECT_INFO – nazwa źródła danych ODBC,

HS_FDS_TRACE_LEVEL – poziom śledzenia informacji o połączeniu ze źródłem,

HS_FDS_SHAREABLE_NAME – lokalizacja sterownika ODBC dla źródła,

HS_LANGUAGE – standard kodowania w źródle,

set ODBCINI – wskazanie lokalizacji pliku z definicją źródła,

set LD_LIBRARY_PATH – ustawienie ścieżki przeszukiwania bibliotek.

Zapisz plik i zamknij edytor.

Strona 30 z 51

4. Dokonamy teraz rekonfiguracji procesu nasłuchu Oracle Listener, aby współpracował ze

źródłem danych ODBC za pośrednictwem Oracle Gateways. Przejdź do katalogu

$ORACLE_HOME/network/admin i otwórz do edycji plik listener.ora. W sekcji

SID_LIST_LISTENER dodaj kolejną podsekcję SID_DESC (istniejąca sekcja SID_DESC o

nazwie dg4db2 odpowiada za komunikację z DB2 – nie zmieniaj jej!). Zawartość pliku po

zmianach przedstawiono poniżej (kolorem czerwonym zaznaczono nową sekcję).

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = integracja_mw)(PORT = 1521))

)

)

SID_LIST_LISTENER=

(SID_LIST=

(SID_DESC=

(SID_NAME=dg4db2)


(PROGRAM=dg4db2)

)

(SID_DESC=

(SID_NAME=mysqlodbc)


(ENVS="LD_LIBRARY_PATH=/usr/lib:/u01/app/oracle/product/11.2.0/dbhome_1/lib")

(PROGRAM=dg4odbc)

)

)

ADR_BASE_LISTENER = /u01/app/oracle

5. Dokonaj restartu procesu nasłuchu Oracle Listener poleceniami lsnrctl stop

i lsnrctl start , następnie sprawdź status usług, jakie aktualnie Oracle Listener

zapewnia (polecenie lsnrctl status). Zwróć uwagę na komunikat Instancja

"mysqlodbc" ….

6. Teraz zdefiniujemy nazwę, pod którą użytkownik systemu Oracle będzie odwoływał się do

źródła danych w postaci serwera MySQL. W tym celu otwórz do edycji plik tnsnames.ora (z

tego samego katalogu co plik listener.ora) a następnie dodaj do pliku wpis:

mysqlakademiki =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = tcp)(HOST = integracja_mw)(PORT = 1521))

(CONNECT_DATA = (SID = mysqlodbc))

(HS = OK)

)

Powyższy wpis określa, że adresując obiekty w serwerze MySQL użytkownik serwera Oracle

będzie posługiwał się nazwą mysqlakademiki. Zapisz zmiany i zakończ edycję pliku. Sprawdź

poprawność dokonanego wpisu poleceniem tnsping mysqlakademiki.

7. Uruchom narzędzie Oracle SQL Developer, następnie przyłącz się do bazy baza01 jako

użytkownik integracja z hasłem oracle.

Strona 31 z 51

8. Podobnie jak w ćwiczeniu z DB2, do komunikacji ze zdalnym serwerem przy pomocy ODBC

konieczne jest utworzenie łącza bazodanowego. Parametry łącza są następujące:

nazwa łącza: mysqlakademiki,

nazwa użytkownika w bazie danych MySQL: „akademiki_u” (nazwa użytkownika w

cudzysłowie!),

hasło użytkownika w bazie danych DB2: „akademiki_u” (hasło w cudzysłowie!),

wskazanie zdalnej bazy danych: mysqlakademiki.

Utwórz to łącze.

9. Sprawdź działanie utworzonego łącza bazodanowego. Spróbuj odczytać dane z tabel

umieszczonych w bazie danych MySQL wykonując w Oracle SQL Developer następujące

polecenia:

SELECT * FROM "domy_studenckie"@mysqlakademiki;

SELECT * FROM "przyznane_miejsca"@mysqlakademiki;

Zwróć uwagę na nazwy tabel w cudzysłowie. Również przy odwołaniu w zapytaniu do

poszczególnych kolumn tabel z bazy AKADEMIKI ich nazwy również należy otoczyć

cudzysłowem, np.:

SELECT "nazwa" FROM "domy_studenckie"@mysqlakademiki;

10. Utwórz dwie perspektywy o nazwach DOMY_STUDENCKIE_V i PRZYZNANE_MIEJSCA_V, które

ułatwią nam późniejsze operacje na danych z serwera MySQL.

CREATE VIEW domy_studenckie_v AS

SELECT "symbol" AS SYMBOL, "nazwa" AS NAZWA, "liczba_miejsc" AS LICZBA_MIEJSC

FROM"domy_studenckie"@mysqlakademiki;

CREATE VIEW przyznane_miejsca_v AS

…

Perspektywy powinny umożliwić odwołanie do poszczególnych kolumn tabel bez

konieczności ujmowania ich w cudzysłów, np.:

SELECT nazwa FROM domy_studenckie_v;

SELECT student, rok_akademicki FROM przyznane_miejsca_v;

Strona 32 z 51

Punkty dodatkowe (11. – 13.) – do wykonania jeśli pozostał jeszcze czas.

11. Spróbuj w Oracle SQL Developer za pomocą perspektywy DOMY_STUDENCKIE_V dodać nowy

dom studencki o symbolu DS5, nazwie Dom studencki nr 5 i liczbie miejsc równej 200.

Następnie sprawdź zawartość tabeli DOMY_STUDENCKIE przy pomocy narzędzia isql.

Zatwierdź transakcję (polecenie commit) w Oracle SQL Developer. Wykonaj ponownie

zapytanie w isql.

12. Wykonaj w isql polecenie (delete from), które usunie z tabeli DOMY_STUDENCKIE

uprzednio dodany rekord. Zaraz po wykonaniu operacji odczytaj w Oracle SQL Developer

zawartość perspektywy DOMY_STUDENCKIE_V.

13. Wykonaj w isql dwa polecenia, definiujące w tabeli DOMY_STUDENCKIE dwa nowe

akademiki, DS6 i DS7, jako jedną transakcję. Początek transakcji oznacz poleceniem begin,

następnie wykonaj dwa polecenia insert. Sprawdź w Oracle SQL Developer zawartość

perspektywy DOMY_STUDENCKIE_V. Czy widzisz dodane akademiki? Zakończ w isql bieżącą

transakcję poleceniem commit. Ponownie odczytaj zawartość perspektywy

DOMY_STUDENCKIE_V, następnie usuń przy jej pomocy akademiki o symbolach DS6 i DS7.

Koniec punktów dodatkowych

14. Wyjdź z programu isql, zamknij terminal i Oracle SQL Developer.

Strona 33 z 51

Ć wićzenie 3.

Kolejne ćwiczenie pokaże możliwość dostępu z systemu zarządzania bazą danych Oracle do danych,

przechowywanych w plikach płaskich. Studium Języków Obcych naszej Wirtualnej Uczelni dostarcza

do dziekanatu oceny, jakie studenci zdobyli w poszczególnych semestrach akademickich z lektoratów

języków obcych, w postaci tekstowego pliku płaskiego o następującej strukturze:

identyfikator studenta, który zdobył ocenę – liczba,

określenie semestru akademickiego, w którym została wystawiona ocena – ciąg znaków w

postaci „<numer roku> <skrót rodzaju semestru>”, np. „2009/10 z” dla semestru zimowego w

roku 2009/10,

numer semestru studiów studenta – liczba,

nazwa przedmiotu – ciąg znaków,

zdobyta ocena – ciąg znaków (ocena wyrażona słownie lub liczbowo).

Przykładowa część zawartości pliku została przedstawiona poniżej:

2888;2004/05 l;6;Język angielski;dobry

2888;2004/05 l;6;Język niemiecki;2

2686;2004/05 l;6;Język angielski;bardzo dobry

2686;2004/05 l;6;J. niemiecki;4

3004;2004/05 l;6;J. angielski;dostateczny

3004;2004/05 l;6;J. niemiecki;5


2937;2005/06 l;8;Język angielski;niedostateczny


3087;2004/05 l;6;J. niemiecki;5

Uwaga! Nazwy przedmiotów mogą być w postaci zarówno „Język angielski” jak i „J. angielski”,

natomiast oceny mogą być podane zarówno w formie liczbowej jak i opisowej.

Plik z danymi nosi nazwę oceny_lektorat.txt, został umieszczony na serwerze w katalogu

/home/oracle/SJO i zawiera dokładnie 14 688 ocen z lektoratów z języków: angielskiego,

niemieckiego i francuskiego. Chcemy, aby pracownicy Działu Kształcenia mieli dostęp do danych z

tego pliku za pośrednictwem bazy danych Oracle.

1. Otwórz terminal jako użytkownik oracle, przejdź do wskazanego katalogu i obejrzyj zawartość

pliku z ocenami.

2. Uruchom narzędzie Oracle SQL Developer, przyłącz się do bazy baza01 jako użytkownik

integracja z hasłem oracle.

3. Dostęp do katalogów w systemie plików serwera bazodanowego Oracle jest realizowany za

pośrednictwem obiektu o nazwie katalog (ang. directory). Polecenie tworzenia katalogu

przedstawiono poniżej:

CREATE DIRECTORY <nazwa obiektu> AS 'ścieżka do katalogu w systemie plików

serwera';

Strona 34 z 51

4. Sprawdź w perspektywie systemowej ALL_DIRECTORIES, czy w Twoim schemacie istnieje

obiekt katalog (ang. directory) o nazwie SJO. Obiekt powinien wskazywać na katalog

/home/oracle/SJO w systemie plików serwera bazy danych. Jeśli obiekt katalog nie istnieje,

utwórz go.

SELECT * FROM all_directories WHERE directory_name = 'SJO';

nie wybrano żadnych wierszy

CREATE DIRECTORY ...

Katalog został utworzony.

SELECT * FROM all_directories WHERE directory_name = 'SJO';

OWNER DIRECTORY_NAME DIRECTORY_PATH

---------- ------------------- ------------ -------------------------

SYS SJO /home/oracle/SJO

5. W dalszej części ćwiczenia utworzymy tabelę zewnętrzną, przy pomocy której będziemy

wykonywać dostęp do danych z pliku oceny_lektorat.txt, przy użyciu katalogu SJO.

Źródłem danych dla tabeli zewnętrznej jest plik, zlokalizowany w systemie plików serwera

bazy danych. Użycie tabeli zewnętrznej jest identyczne jak zwykłej tabeli (zapytania SQL,

możliwość użycia w programach PL/SQL, itd.). W momencie wykonywania zapytania do tabeli

zewnętrznej wywoływane jest odpowiednie oprogramowanie: Oracle SQL*Loader lub Oracle

Data Pump (zależnie od typu tabeli), które realizuje operacje na przyłączonym do tabeli pliku.

Operacje, jakie można wykonać na tabeli zewnętrznej, zależą od jej typu oraz typu pliku:

plik tekstowy – możliwy tylko odczyt (typ tabeli ORACLE_LOADER),

plik binarny w formacie backup-u SZBD Oracle – możliwe jednokrotne przesłanie danych

z bazy danych do pliku (przy tworzeniu tabeli), potem tylko odczyt (typ tabeli

ORACLE_DATAPUMP).

Polecenie tworzące tabelę zewnętrzną przedstawiono poniżej:

CREATE TABLE <nazwa_tabeli> (<definicja atrybutów tabeli>)

ORGANIZATION EXTERNAL // tabela będzie pobierać dane z pliku

(type [oracle_loader | oracle_datapump] // typ oprogram. wczytującego dane

default directory <obiekt DIRECTORY> // katalog z plikiem danych

access parameters

(records delimited by newline // rekordy w osobnych liniach pliku

badfile <[obiekt DIRECTORY>:]'<nazwa pliku błędów>' // plik - log błędów

logfile <[obiektu DIRECTORY>:]'<nazwa pliku logu>' // plik - log operacji

skip <liczba> // ile początkowych linii pliku pominąć przy wczytywaniu

fields terminated by '<znak oddzielający wartości w rekordzie>'

fields (<definicja pól>) // opcjonalna definicja pól pliku

missing field values are null) // czy pola bez wartości pozostaną puste

location ([obiekt DIRECTORY:]'<nazwa pliku danych>'))

reject limit [0 | <wartość> | UNLIMITED]; // ile dopuszczalnych błędów przy

wczytaniu pliku

Strona 35 z 51

6. Sprawdź, czy w schemacie użytkownika integracja znajdują się wcześniej utworzone tabele

zewnętrzne. W tym celu wykonaj zapytanie do perspektywy systemowej

USER_EXTERNAL_TABLES.

SELECT table_name, type_name, default_directory_name, reject_limit

FROM user_external_tables;

7. Zaprojektuj tabele zewnętrzną o nazwie OCENY_LEKTORAT_ZEW i następującym schemacie:

student_id – liczba całkowita o precyzji 6 (typ NUMBER(6)),

rok_semestr_akademicki – ciąg znaków o zmiennej długości, maks. 10 znaków (typ

VARCHAR2(10)),

semestr_studiow – liczba całkowita o precyzji 2 (typ NUMBER(2)),

przedmiot – ciąg znaków o zmiennej długości, maks. 60 znaków, (typ VARCHAR2(60))

ocena – ciąg znaków o zmiennej długości, maks. 20 znaków (typ VARCHAR2(20)).

Tabela będzie wypełniana danymi z pliku oceny_lektorat.txt z katalogu SJO. Jako

oprogramowanie wczytujące dane wybierz Oracle SQL*Loader. Dodatkowe pliki,

wykorzystywane podczas importu danych z pliku oceny_lektorat.txt, to:

plik z rekordami błędnymi – oceny_lektorat.txt.bad,

plik logu – oceny_lektorat.txt.log,

Oba pliki mają zostać umieszczone w katalogu SJO. Pobranie danych z pliku ma zostać

przerwane jeśli jakikolwiek rekord w pliku będzie błędny (reject limit 0).

CREATE TABLE oceny_lektorat_zew (...)

ORGANIZATION EXTERNAL(...);

8. Sprawdź działanie tabeli zewnętrznej. W tym celu wykonaj zapytanie, które odczyta wszystkie

rekordy z tabeli OCENY_LEKTORAT_ZEW. Następnie sprawdź plik logu operacji

(oceny_lektorat.txt.log w katalogu /home/oracle/SJO) – użyj edytora gedit do otwarcia pliku

(wykonaj w terminalu polecenie gedit

/home/oracle/SJO/oceny_lektorat.txt.log).

SELECT * FROM oceny_lektorat_zew;

9. Dodaj do pliku oceny_lektorat.txt nową linię, zawierającą poniższy tekst (użyj w terminalu

edytora gedit):

3347;2005/06 z;8i;J. niemiecki;dostateczny

Ponownie wykonaj zapytanie do tabeli OCENY_LEKTORAT_ZEW, wyszukując dane dodanej

oceny.

SELECT * FROM oceny_lektorat_zew WHERE student_id = 3347;

Co zaobserwowałaś/eś?

10. Odczytaj ponownie zawartość pliku logu a następnie zawartość pliku z błędnymi rekordami.

Strona 36 z 51

11. Zmień definicję tabeli OCENY_LEKTORAT_ZEW tak, aby zapytanie do niej dawało wynik

również wtedy, gdy w pliku znajdzie się co najwyżej 10 błędnych rekordów (podpowiedź:

najpierw usuń definicję tabeli poleceniem drop table <nazwa tabeli>, następnie

ponownie utwórz tabelę zewnętrzną z opcją REJECT LIMIT ustawioną na wartość 10).

Sprawdź działanie tabeli.

12. Część danych, które udostępnia tabela zewnętrzna OCENY_LEKTORAT_ZEW z pliku

oceny_lektorat.txt, nie zachowuje spójnego formatu. Chodzi o kolumny przedmiot oraz

ocena. Wykonaj poniższe zapytania, aby znaleźć wszystkie wartości tych kolumn.

SELECT distinct przedmiot

FROM oceny_lektorat_zew;

PRZEDMIOT

-----------------------

J. francuski

J. angielski

Język angielski

Język francuski

Język niemiecki

J. niemiecki

SELECT distinct ocena

FROM oceny_lektorat_zew;

OCENA

--------------------

niedostateczny

dobry

bardzo dobry

3

dostateczny

5

2

4

Chcemy doprowadzić dane do spójnego formatu: w nazwach przedmiotów skrót "J."

zastąpimy słowem "Język", natomiast oceny przetransformujemy do postaci liczbowej.

Dodatkowo atrybut rok_semestr_akademicki, definiujący semestr przyznania oceny (np.

"2005/06 z") zastąpimy parą atrybutów, jeden dla roku akademickiego ("2005/06"), drugi dla

rodzaju semestru ("zimowy"). Przy realizacji transformacji posłużymy się mechanizmem

funkcji tablicowych.

13. Funkcja tablicowa to składowana w bazie danych funkcja PL/SQL, zwracająca jako wynik

zbiór rekordów. Może być traktowana jak tabela – umieszczana w zapytaniu w klauzuli

FROM. Funkcja tablicowa służy najczęściej do realizacji złożonych transformacji danych.

Pierwszym krokiem przy definicji funkcji tablicowej będzie zdefiniowanie trwałego typu

rekordowego, określającego strukturę rekordu ze zbioru rekordów, jakie będzie zwracać

nasza funkcja tablicowa. Składnię polecenia tworzącego typ rekordowy przedstawiono

poniżej.

CREATE [OR REPLACE] TYPE <nazwa> AS OBJECT(<definicje atrybutów>);

Strona 37 z 51

W naszym przypadku rekord, zwracany przez funkcję tablicową, będzie miał następując

strukturę:

student_id, typ number(6),

rok_akademicki, typ varchar2(7),

rodzaj_semestru, typ varchar2(6),

semestr_studiow, typ number(2),

przedmiot, typ varchar2(60),

ocena, typ number(3,2).

Utwórz typ obiektowy o nazwie tOcena i strukturze jak powyżej. Strukturę utworzonego typu

możesz podejrzeć poleceniem describe <nazwa typu>.

CREATE TYPE tOcena AS OBJECT(…);

describe tOcena;

14. W drugim kroku musimy zdefiniować typ tablicowy, który będzie korzystał ze zdefiniowanego

w kroku poprzednim typu rekordowego. Składnia definicji typu tablicowego jest następująca:

CREATE [OR REPLACE] TYPE <nazwa> AS TABLE OF <typ bazowy>;

Typ tablicowy będzie nosił nazwę tTablicaOcen, polecenie go definiujące umieszczono

poniżej.

CREATE TYPE tTablicaOcen AS TABLE OF tOcena;

15. Przystąpimy teraz do definicji funkcji tablicowej. Schemat polecenia tworzącego funkcję

tablicową przedstawiono poniżej.

CREATE [OR REPLACE] FUNCTION <nazwa> RETURN <typ_tablicowy> PIPELINED IS

...

BEGIN

...

PIPE ROW(<rekord>);

...

END;

Polecenie PIPE ROW w ciele funkcji przesyła do tablicy, zwracanej przez funkcję, jeden

rekord.

16. Sygnatura naszej funkcji powinna być następująca:

CREATE FUNCTION OCENY_LEKTORAT_ZEW_TAB RETURN tTablicaOcen PIPELINED IS

Zadeklarujemy kursor, który będzie udostępniał wszystkie rekordy tabeli

OCENY_LEKTORAT_ZEW.

cursor cOceny is SELECT * FROM oceny_lektorat_zew ORDER BY student_id;

Strona 38 z 51

Następnie zaprojektuj pętlę FOR z kursorem, w której przeglądniesz wszystkie rekordy

pobrane przez kursor i skonstruujesz rekord o strukturze zdefiniowanej przez typ tOcena,

który następnie zwrócisz poleceniem PIPE ROW. Pamiętaj o ujednoliceniu formatu nazw

przedmiotów i ocen. Podpowiedź: konstrukcja rekordu to wywołanie konstruktora typu

tOcena z parametrami będącymi wartościami dla poszczególnych pól rekordu, np.:

PIPE ROW(tOcena(1234, '2005/06', 'zimowy', 5, 'Język angielski', 3.0));

Kod funkcji, realizujący powyższe zadania, może wyglądać np. tak:

CREATE FUNCTION oceny_lektorat_zew_tab

RETURN tTablicaOcen pipelined IS

CURSOR cOceny IS

SELECT * FROM oceny_lektorat_zew ORDER BY student_id;

vNazwaPrzedmiotu varchar2(60);

vOcena number(3,2);

vRok varchar2(7);

vRodzajSemestru varchar2(6);

BEGIN

FOR O IN cOceny LOOP

-- Konwersja nazwy przedmiotu

IF substr(O.przedmiot, 1, 2) = 'J.' THEN

vNazwaPrzedmiotu := replace(O.przedmiot, 'J.', 'Język');

ELSE

vNazwaPrzedmiotu := O.przedmiot;

END IF;

-- Konwersja oceny

CASE O.ocena

WHEN 'niedostateczny' THEN vOcena := 2;

WHEN 'dostateczny' THEN vOcena := 3;

WHEN 'dobry' THEN vOcena := 4;

WHEN 'bardzo dobry' THEN vOcena := 5;

ELSE vOcena := to_number(O.ocena);

END CASE;

-- Transformacja nazwy semestru

vRok := substr(O.rok_semestr_akademicki,1,7);

CASE substr(O.rok_semestr_akademicki,9,1)

WHEN 'z' THEN vRodzajSemestru := 'zimowy';

WHEN 'l' THEN vRodzajSemestru := 'letni';

END CASE;

-- Przesłanie rekordu do tablicy

PIPE ROW(tOcena(O.student_id, vRok, vRodzajSemestru,

O.semestr_studiow, vNazwaPrzedmiotu, vOcena));

END LOOP;

return;

END oceny_lektorat_zew_tab;

Strona 39 z 51

17. Wykorzystanie funkcji tablicowej w zapytaniach przedstawia poniższy schemat:

SELECT <lista kolumn> FROM TABLE(funkcja_tablicowa);

18. Wywołaj utworzoną przez siebie funkcję tablicową i sprawdź poprawność jej działania.

Zauważ, że dane w pliku tekstowym a także dane w tabeli zewnętrznej

OCENY_LEKTORAT_ZEW nie uległy zmianie.

19. Zamknij narzędzie Oracle SQL Developer.

Strona 40 z 51

Ć wićzenie 4.

W bieżącym ćwiczeniu spróbujemy zintegrować nasz Dział Kształcenia z Dziekanatem Wirtualnej

Uczelni. Naszym celem jest pobranie z Dziekanatu danych osobowych studentów oraz danych o

uzyskanych przez studentów ocenach. Dziekanat korzysta z tego samego systemu zarządzania bazą

danych co Dział Kształcenia, a więc Oracle 11g. Serwer dziekanatowy jest zainstalowany na innym

komputerze. Przeprowadzimy proces konfiguracji homogenicznego środowiska tzw. asynchronicznej

replikacji danych.

1. W pierwszym kroku dokonamy konfiguracji oprogramowania Oracle Net Services w celu

umożliwienia podłączenia z naszego lokalnego serwera bazodanowego danych Oracle do

zdalnego serwera bazodanowego Oracle o nazwie dblab01. Konfiguracja sprowadza się do

dodania odpowiedniego wpisu (patrz poniżej) w pliku

$ORACLE_HOME/network/admin/tnsnames.ora. (otwórz terminal jako użytkownik oracle,

przejdź do katalogu $ORACLE_HOME/network/admin, uruchom edycję pliku poleceniem

gedit tnsnames.ora).

DBLAB01 =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = admlab2-main.cs.put.poznan.pl)(PORT

= 1521))

)

(CONNECT_DATA =

(SERVICE_NAME = dblab01.cs.put.poznan.pl)

)

)

Serwer działa na komputerze o adresie admlab2-main.cs.put.poznan.pl, proces nasłuchujący

żądań klientów zajmuje port 1521. Nazwa usługi bazodanowej na serwerze to

dblab01.cs.put.poznan.pl. Pod tą samą nazwą będziemy się odwoływać do tego serwera z

naszego komputera. Do konfiguracji Oracle Net Services możesz również użyć programu

netca.

2. Sprawdź poprawność dokonanej konfiguracji, wykonując w terminalu polecenie tnsping

dblab01.

Strona 41 z 51

3. Uruchom narzędzie Oracle SQL Developer. Dodamy w nim opis połączenia, korzystającego ze

skonfigurowanego przed chwilą pliku tnsnames.ora. W oknie Connections kliknij prawym

przyciskiem myszy na pozycję Connections i z wyświetlonego menu kontekstowego wybierz

opcję New Connection….

4. W wyświetlonym oknie New / Select Database Connection:

w polu Connection Name wpisz nazwę połączenia: dblab01

w polu Connection Type wybierz wartość TNS

w polu Network Alias wybierz wartość DBLAB01

Naciśnij przycisk Save a następnie Anuluj. W oknie Connections powinien pojawić się opis

nowego połączenia.

Strona 42 z 51

5. W bazie dblab01 masz konto bazodanowe o nazwie utworzonej z dodania do Twojego

nazwiska przedrostka "sphd_" oraz dołączenia przyrostka w postaci pierwszej litery imienia

(np. sphd_kowalski_j dla Jana Kowalskiego) i haśle będącym Twoim imieniem (zarówno

nazwa jak i hasło składają się z małych liter bez polskich znaków diakrytycznych). Spróbuj

przyłączyć się do swojego konta na serwerze dblab01. Sprawdź, jakie tabele masz utworzone

w swoim schemacie.

SELECT table_name FROM user_tables ORDER BY table_name;

TABLE_NAME

------------------------------

KATEGORIE_STUDIOW

KIERUNKI_STUDIOW

MIASTA

OCENY

PRZEDMIOTY

RODZAJE_OCEN

RODZAJE_STUDIOW

RODZAJE_ZAJEC

RODZAJE_ZALICZEN

SEMESTRY_AKADEMICKIE

STUDENCI

Schemat zawiera główną część danych naszej wirtualnej uczelni, mianowicie dane osobowe

studentów wraz z przebiegiem studiów oraz uzyskanymi ocenami i zaliczeniami. Będziemy

chcieli pobrać te dane do bazy integrującej informacje różnych jednostek naszej wirtualnej

uczelni (czyli do danych użytkownika integracja w lokalnej bazie baza01).

6. Przyłącz się w narzędziu Oracle SQL Developer do użytkownika integracja w bazie baza01.

Połączenie z Twoim użytkownikiem w bazie dblab01 pozostaw aktywne (w tekście ćwiczenia

do nazwy Twojego użytkownika będziemy się odwoływać przez nazwę sphd_uzytkownik).

Przełączanie się między aktywnymi połączeniami jest możliwe za pośrednictwem zakładek.

7. Zdefiniujemy teraz łącze bazodanowe, pozwalające na dostęp z bazy danych baza01 do bazy

danych dblab01. Łącze o nazwie dblabdaneosobowe będzie własnością użytkownika

integracja i będzie wskazywać na schemat użytkownika sphd_uzytkownik w bazie dblab01.

Wykonaj odpowiednie polecenie w zakładce baza01, następnie przetestuj poprawność

działania łącza.

CREATE DATABASE LINK dblabdaneosobowe ...

SELECT count(*) FROM studenci@dblabdaneosobowe;

COUNT(*)

----------

12615

Strona 43 z 51

8. Do tej pory aby ukryć lokalizację zdalnego obiektu (czyli obiektu, do którego dostęp

umożliwia łącze bazodanowe) w poleceniu SQL, używaliśmy perspektywy. Innym

mechanizmem, często używanym w tym celu, jest synonim. Synonim jest alternatywną

nazwą dla obiektu. Schemat polecenia tworzącego synonim przedstawiono poniżej:

CREATE SYNONYM <synonim> FOR <nazwa obiektu oryginalnego>;

9. Utwórz synonim studencidblab, który ukryje nazwę studenci@dblabdaneosobowe. Następnie

użyj synonimu w zapytaniu.

CREATE SYNONYM ...

select count(*) from studencidblab;

10. Dane, które zintegrowaliśmy w poprzednich ćwiczeniach, nie były kopiowane do serwera

baza01 z miejsc ich oryginalnych lokalizacji, a jedynie do źródeł, gdzie dane są

przechowywane, były wysyłane odpowiednie polecenia SQL. Taki sposób integracji nie

zabezpiecza środowiska przed ewentualnymi awariami sieci komunikacyjnej, powodującej

niedostępność danych ze zdalnych źródeł. Tym razem chcemy, aby dane z serwera dblab01

były dostępne dla użytkownika integracja w baza01 nawet w sytuacji niedostępności serwera

dblab01. Zbudujemy środowisko replikacji danych.

Replikacja to proces kopiowania danych z jednego miejsca (źródła danych) do miejsca

docelowego. W relacyjnych bazach danych źródłem danych będzie tabela, nazywana tabelą

źródłową, natomiast obiekt docelowy, do którego trafią skopiowane dane, nosi nazwę

repliki. Kopiowanie danych powtarzane jest okresowo w celu uaktualnienia repliki danymi,

które zostały dodane/zmodyfikowane w tabeli źródłowej. Proces ten jest nazywany

odświeżaniem repliki.

11. Replika w bazach danych Oracle implementowana jest za pomocą tzw. perspektywy

materializowanej. Jest to tabela, składująca w lokalnej bazie danych dane, pobrane z tabel

źródłowych zdalnej bazy danych, do której dołączamy się przy pomocy łącznika

bazodanowego. Perspektywa materializowana definiowana jest przez zapytanie, w którym

umieszczone są odwołania do tabel źródłowych ze zdalnej bazy danych. Jedną z

charakterystycznych cech perspektywy materializowanej, odróżniających ją od zwykłej

perspektywy, jest to, że perspektywa materializowana posiada swoje własne dane oraz że te

dane mogą być odświeżane. Fakt, że perspektywa materializowana posiada własne dane,

powoduje, że połączenie ze zdalną bazą danych jest konieczne tylko w momencie

wypełnienia repliki danymi oraz podczas procesu odświeżania. Użytkownicy korzystają z

danych zdalnych wykonując dostęp do ich lokalnej kopii, a więc do repliki. Z kolei proces

odświeżania perspektywy materializowanej polega na uaktualnieniu jej zawartości danymi,

które uległy zmianie (np. zostały zmodyfikowane) w tabelach źródłowych repliki. Proces

odświeżania jest charakteryzowany dwoma podstawowymi parametrami: (1) w jaki sposób

odświeżyć replikę oraz (2) kiedy zrealizować proces odświeżania.

Strona 44 z 51

Jeśli chodzi o sposób odświeżenia, to perspektywa materializowana może być odświeżana:

całkowicie – bieżąca zawartość perspektywy zostaje usunięta, perspektywa zostaje

ponownie wypełniona danymi z tabel źródłowych,

przyrostowo – do bieżącej zawartości perspektywy materializowanej zostają

dodane/usunięte/ zmodyfikowane dane, które uległy zmianom w tabelach źródłowych

od momentu ostatniej realizacji procesu odświeżenia.

Z kolei z uwagi na moment odświeżenia perspektywy materializowane możemy podzielić na:

odświeżane okresowo – proces odświeżania jest realizowane co zadany okres czasu (np.

co 10 minut),

odświeżane na żądanie – odświeżanie jest uruchamiane ręcznie przez użytkownika,

nigdy nie odświeżane – perspektywa zostaje wypełniona danymi tylko raz, nie jest potem

nigdy odświeżana.

Składnię polecenia tworzącego perspektywę materializowaną przedstawiono poniżej.

CREATE MATERIALIZED VIEW <nazwa perspektywy>

<moment pierwszego wypełnienia danymi>

{never refresh | <sposób odświeżania> <moment odświeżania>}

WITH <sposób identyfikacji rekordów>

AS <zapytanie do tabel źródłowych>;

gdzie:

moment pierwszego wypełnienia danymi:

build immediate – wypełnij perspektywę danymi zaraz po utworzeniu,

build deferred – wypełnij perspektywę danymi przy pierwszym odświeżaniu,

never refresh – perspektywa nigdy nie będzie odświeżana,

sposób odświeżania:

refresh complete – odświeżanie całkowite,

refresh fast – odświeżanie przyrostowe,

refresh force – system sam wybierze rodzaj odświeżania,

moment odświeżania:

on demand – odświeżania na żądanie użytkownika,

start with – wyrażenie definiujące moment pierwszej realizacji procesu

odświeżenia, np.:

start with sysdate – pierwsze odświeżenie zaraz po utworzeniu repliki,

start with sysdate+1/24 – pierwsze odświeżenie po 1 godzinie od utworzenia

repliki,

next – wyrażenie definiujące moment kolejnej realizacji procesu odświeżenia, np.:

next sysdate+1/1440 – odświeżanie będzie realizowane co 1 minutę (1440 =

24h * 60 minut),

next sysdate+1/4320 – odświeżanie będzie realizowane co 20 sekund (4320 =

24h * 60 minut * 3),

sposób identyfikacji rekordów repliki:

Strona 45 z 51

with rowid – powiązanie między rekordami perspektywy i tabeli źródłowej

realizowane jest na podstawie adresu rekordu,

with primary key – powiązanie między rekordami perspektywy i tabeli źródłowej

realizowane jest na podstawie wartości klucza głównego tabeli źródłowej.

Informacje słownikowe dotyczące perspektyw materializowanych:

USER_MVIEWS – lista perspektyw materializowanych, będących własnością użytkownika:

NAME – nazwa perspektywy,

MASTER – nazwa tabeli źródłowej,

MASTER_LINK – nazwa łącznika bazodanowego do bazy danych tabeli źródłowej,

REFRESH_METHOD – sposób identyfikacji rekordów,

TYPE – sposób odświeżenia (FAST, FORCE, COMPLETE, NEVER),

NEXT – wyrażenie definiujące moment następnego odświeżenia,

START WITH – wyrażenie definiujące moment pierwszego wypełnienia,

QUERY – tekst zapytania.

USER_MVIEW_REFRESH_TIMES –informacje o momencie ostatniej realizacji odświeżenia

perspektywy:

NAME – nazwa perspektywy,

LAST_REFRESH – moment realizacji ostatniego procesu odświeżania.

Perspektywa odświeżana całkowicie

12. Jako użytkownik integracja utwórz, korzystając z Oracle SQL Developer, perspektywę

materializowaną STUDENCI_MV, która będzie pobierać dane z relacji STUDENCI z bazy

dblab01. Parametry perspektywy są następujące:

nazwa perspektywy: STUDENCI_MV,

pierwsze wypełnienie danymi po 1 minucie od utworzenia,

replika ma być odświeżana całkowicie,

odświeżanie ma być realizowane co 2 minuty,

sposób identyfikacji rekordów repliki: za pomocą klucza głównego,

zakres danych, pobieranych z tabeli źródłowej STUDENCI: wszystkie dane.

CREATE MATERIALIZED VIEW studenci_mv ...;

Zmaterializowana perspektywa została utworzona.

Następnie sprawdź, czy utworzona perspektywa zawiera dane – wykonaj do niej przykładowe

zapytanie.

SELECT * FROM studenci_mv

WHERE kierunek = 'NZK3' AND plec = 'kobieta' ORDER BY student_id;

nie wybrano żadnych wierszy

Po ok. 2 minutach ponownie sprawdź, czy perspektywa zawiera dane.

SELECT * FROM studenci_mv

WHERE kierunek = 'NZK3' AND plec = 'kobieta' ORDER BY student_id;

Strona 46 z 51

STUDENT_ID KIERUNEK MIASTO_ID DATA_UR PLEC

---------- -------- ---------- -------- ---------

771 NZK3 2320 82/09/13 kobieta

1745 NZK3 1583 78/02/07 kobieta

1949 NZK3 1593 71/06/15 kobieta

9424 NZK3 1703 84/06/12 kobieta

10665 NZK3 1816 86/05/24 kobieta

11010 NZK3 2309 86/10/21 kobieta

11036 NZK3 1593 83/01/01 kobieta

13058 NZK3 1569 82/05/09 kobieta

16380 NZK3 2382 88/01/30 kobieta

9 wierszy zostało wybranych.

13. W Oracle SQL Developer w zakładce użytkownika sphd_uzytkownik (baza dblab01) dodaj do

tabeli STUDENCI w bazie dblab01 nowy rekord opisujący studentkę o identyfikatorze 99999

na kierunku NZK3 z miasta o identyfikatorze 5377, urodzonej 1 stycznia 1994 r.. Pamiętaj o

zakończeniu transakcji poleceniem commit.

INSERT INTO studenci VALUES(99999, 'NZK3', 5377, DATE '1994-01-01',

'kobieta');

commit;

14. Przejdź do zakładki użytkownika integracja i ponownie wykonaj ostatnie zapytanie z punktu

12. Odczekaj ok. 2 minut i ponów zapytanie – czy w replice pojawił się rekord dodany w bazie

dblab01?

STUDENT_ID KIERUNEK MIASTO_ID DATA_UR PLEC

---------- -------- ---------- -------- ---------

771 NZK3 2320 82/09/13 kobieta

1745ZK NZK3 1583 78/02/07 kobieta

1949 NZK3 1593 71/06/15 kobieta

9424 NZK3 1703 84/06/12 kobieta

10665 NZK3 1816 86/05/24 kobieta

11010 NZK3 2309 86/10/21 kobieta

11036 NZK3 1593 83/01/01 kobieta

13058 NZK3 1569 82/05/09 kobieta

16380 NZK3 2382 88/01/30 kobieta

99999 NZK3 5377 94/01/01 kobieta

10 wierszy zostało wybranych.

15. Sprawdź w perspektywie systemowej USER_MVIEW_REFRESH_TIMES, kiedy została

odświeżona replika STUDENCI_MV. W tym celu wykonaj poniższe zapytanie:

SELECT to_char(last_refresh,'yyyy.mm.dd hh24:mi:ss') AS last_refresh

FROM user_mview_refresh_times WHERE name = 'STUDENCI_MV';

Strona 47 z 51

Informacje o momencie ostatniego odświeżenia oraz jego typie (całkowite czy przyrostowe)

możesz również uzyskać z perspektywy systemowej USER_MVIEWS:

SELECT last_refresh_type, to_char(last_refresh_date,'yyyy.mm.dd hh24:mi:ss')

AS last_refr_date

FROM user_mviews WHERE mview_name = 'STUDENCI_MV';

Perspektywa odświeżana przyrostowo

16. Utworzymy teraz perspektywę materializowana odświeżaną przyrostowo. Aby taki sposób

odświeżania mógł być realizowany, muszą być spełnione dwa warunki:

perspektywa materializowana musi być tzw. perspektywą prostą – zapytanie ją

definiujące nie może zawierać m.in. połączeń, grupowania, funkcji agregujących i

analitycznych, klauzuli DISTINCT,

dla tabeli źródłowej w zdalnej bazie danych musi zostać utworzony dziennik,

przechowujący informacje o zmianach, jakie zostały zrealizowane na danych tabeli – jest

to tzw. dziennik perspektywy materializowanej.

Składnię polecenia tworzącego dziennik przedstawiono poniżej.

CREATE MATERIALIZED VIEW LOG ON <nazwa tabeli źródłowej> WITH <sposób

identyfikacji rekordów>;

Dziennik implementowany jest w postaci tabeli o nazwie MLOG$_<nazwa tabeli źródłowej>.

Dziennik tworzymy oczywiście tam, gdzie zlokalizowana jest tabela źródłowa perspektywy, a

więc w bazie zdalnej!

Tym razem utworzymy replikę drugiej tabeli zdalnej, umieszczonej w schemacie użytkownika

sphd_uzytkownik w bazie dblab01. Tabela nosi nazwę OCENY i zawiera informacje o ocenach,

jakie uzyskali ci studenci. Replika ta będzie odświeżana w sposób przyrostowy.

17. Przejdź do zakładki dblab01 (użytkownik sphd_uzytkownik). Następnie utwórz dziennik

perspektywy materializowanej dla tabeli OCENY. Dziennik będzie wspierał identyfikację

rekordów przez adres rekordu (identyfikacja przez klucz główny nie jest możliwa – tabela nie

posiada klucza głównego).

CREATE MATERIALIZED VIEW LOG ...;

Sprawdź, jaka tabela implementuje utworzony dziennik. W tym celu wykonaj poniższe

zapytanie do słownika danych bazy dblab01. Zapisz uzyskaną nazwę (będzie potrzebna w

późniejszej części ćwiczenia).

SELECT log_table FROM user_mview_logs WHERE master = 'OCENY';

Obejrzyj strukturę dziennika (polecenie describe <nazwa>), możesz również odczytać

jego zawartość– jednak na razie powinien być pusty.

SELECT * FROM ...;

18. Przejdź do zakładki baza01 (użytkownik integracja). Następnie utwórz replikę tabeli OCENY z

bazy dblab01 o następujących parametrach:

a. nazwa repliki: OCENY_MV,

Strona 48 z 51

b. pierwsze wypełnienie natychmiast po utworzeniu,

c. odświeżanie przyrostowe,

d. odświeżanie okresowe z częstotliwością co 1 minutę,

e. sposób identyfikacji rekordów: adres rekordu,

f. zakres danych, pobieranych z tabeli źródłowej OCENY: wszystkie dane.

Po utworzeniu spróbuj odczytać dane z repliki.

SELECT count(*) FROM oceny_mv;

19. Jako użytkownik sphd_uzytkownik (zakładka dblab01) wykonaj kilka operacji modyfikacji

danych tabeli OCENY.

INSERT INTO oceny(student_id, rok_akademicki, rodzaj_semestru, przedmiot_id,

ocena)

VALUES(99999,'2006/07','letni',1701,5);

UPDATE oceny SET ocena = 4

WHERE student_id = 1618 AND przedmiot_id = 24 AND rodzaj_zajec = 'W';

DELETE oceny WHERE student_id = 1618 AND przedmiot_id = 24 AND rodzaj_zajec =

'C';

Po modyfikacjach zatwierdź transakcję poleceniem commit.

20. Spróbuj odczytać zawartość dziennika dla tabeli OCENY (nazwa dziennika: MLOG$_OCENY).

M_ROW$$ SNAPTIME DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$ XIDSS

------------------ -------- --------- --------- --------------- ----------------

AAAWD6AAEAABANTAAB 00/01/01 I N FEFF 1688927169729111

AAAWD6AAEAAAuWbAAc 00/01/01 U U 0001 1688927169729111

AAAWD6AAEAAAuWbAAe 00/01/01 D O 0000 1688927169729111

Zwróć uwagę na kolumnę DMLTYPE$$ – zawiera ona informacje o rodzaju operacji, która

zmodyfikowała dane tabeli, dla której utworzono dziennik. Pierwsza kolumna, M_ROW$$

zawiera adres zmodyfikowanego rekordu.

21. Poczekaj, aż nastąpi odświeżenie perspektywy OCENY_MV. Sprawdź, czy zmiany zostały

zreplikowane, następnie ponownie odczytaj zawartość dziennika dla tabeli OCENY.

22. Replika może zostać odświeżona poza ustalonym harmonogramem, na żądanie użytkownika.

Jest to tzw. odświeżanie ręczne. Aby ręcznie odświeżyć perspektywę materializowaną należy

wykonać procedurę REFRESH z pakietu DBMS_MVIEW. Parametry procedury to:

lista perspektyw do odświeżenia,

sposób realizacji procesu odświeżenia:

C – całkowicie,

F – przyrostowo,

? – system sam wybierze odpowiedni sposób odświeżenia (jeśli dostępny jest

dziennik, będzie realizowane odświeżenie przyrostowe; w przypadku braku dziennika

realizowane jest odświeżanie całkowite).

Np. aby ręcznie odświeżyć perspektywy materializowane P1 (przyrostowo) i P2 (całkowicie),

należy wykonać polecenie execute DBMS_MVIEW.REFRESH(’P1, P2’, ’CF’);.

Strona 49 z 51

23. Zażądaj ręcznego odświeżenia perspektyw STUDENCI_MV i OCENY_MV – wykonaj to przy

pomocy jednego polecenia (zakładka baza01).

execute DBMS_MVIEW.REFRESH...

24. Sprawdź w zbiorze perspektyw systemowych, czy i kiedy odświeżenie ręczne perspektyw

materializowanych zostało zrealizowane.

Grupy odświeżania

25. Utworzone przez nas perspektywy materializowane mają różne harmonogramy odświeżania

(STUDENCI_MV co 2 minuty, OCENY_MV co minutę). Może to powodować pewne problemy.

Przeprowadźmy następujący eksperyment:

a. jako użytkownik sphd_uzytkownik dodaj do tabel w bazie dblab01 dane jednego nowego

studenta z dwoma ocenami, np.:

INSERT INTO studenci(student_id, kierunek) VALUES(100000,'NZK3');

INSERT INTO oceny(student_id, przedmiot_id, ocena)

VALUES (100000, 1645, 5);

INSERT INTO oceny(student_id, przedmiot_id, ocena)

VALUES (100000, 1646, 3);

Zatwierdź transakcję poleceniem commit.

b. jako użytkownik integracja sprawdź, czy dane nowego studenta i jego ocen pojawiły się

w perspektywach STUDENCI_MV i OCENY_MV:

SELECT * FROM studenci_mv WHERE student_id = 100000;

SELECT * FROM oceny_mv WHERE student_id = 100000;

Co zaobserwowałaś/eś? (Podpowiedź: dane ocen studenta pojawiły się w bazie baza01 przed

danymi studenta).

Rozwiązaniem zaprezentowanego problem mogłoby być ujednolicenie harmonogramów

odświeżania obu perspektyw. Jednak takie rozwiązanie nie zapobiegnie sytuacji, w której

jedna z perspektyw zostanie odświeżona, natomiast odświeżenie drugiej nie powiedzie się

(np. z powodu awarii sieci). Stosowanym rozwiązaniem jest umieszczenie perspektyw

w jednej grupie odświeżania.

26. Grupa odświeżania pozwala na jednoczesne odświeżanie wielu perspektyw, zapewniając

spójność danych w ramach wszystkich perspektyw z grupy. Typowym zastosowaniem grup

odświeżania jest odświeżanie perspektyw, których tabele źródłowe są połączone kluczem

obcym. Każda grupa odświeżania posiada nazwę, listę perspektyw, oraz zdefiniowany

harmonogram odświeżania perspektyw w grupie (harmonogram odświeżania, ustalony dla

grupy, zastępuje indywidualne harmonogramy perspektyw w grupie).

27. Sprawdź, jakie aktualnie mamy utworzone grupy odświeżania. W tym celu wykonaj zapytanie

do perspektywy systemowej USER_REFRESH (nazwa grupy odświeżania znajduje się w

kolumnie RNAME, kolumna NEXT_DATE przechowuję moment kolejnego odświeżenia

perspektyw w grupie) .

Strona 50 z 51

SELECT rname, to_char(next_date,'yyyy.mm.dd hh24:mi:ss') AS next_date FROM

user_refresh;

Mimo tego, że nie tworzyliśmy dotąd jawnie grup odświeżania, powyższe zapytanie zwróciło

dwa rekordy. Powodem tego jest fakt, że każda perspektywa materializowana zostaje

domyślnie przydzielona do grupy o nazwie równej nazwie perspektywy. Aby sprawdzić, jakie

perspektywy należą do danej grupy odświeżania, wykonaj zapytanie do perspektywy

systemowej USER_REFRESH_CHILDREN.

SELECT name, type FROM user_refresh_children WHERE rname = 'STUDENCI_MV';

SELECT name, type FROM user_refresh_children WHERE rname = 'OCENY_MV';

Jak widać, w każdej grupie odświeżania znajduje się teraz jedna perspektywa

materializowana.

28. Utworzymy teraz nową grupę odświeżania i przydzielimy do niej obie perspektywy

materializowane. Do zdefiniowania grupy odświeżania używa się procedury MAKE z pakietu

DBMS_REFRESH. Parametry procedury są następujące:

name – nazwa grupy (RG_GRUPA_01),

list – lista perspektyw, które mają być odświeżane przez grupę (STUDENCI_MV

i OCENY_MV),

next_date – moment pierwszego odświeżenia perspektyw z grupy (natychmiast),

interval – wyrażenie określające częstotliwość odświeżania perspektyw z grupy (co

1,5 minuty)

implicit_destroy – czy po usunięciu ostatniej perspektywy z grupy ma ona zostać

automatycznie usunięta (domyślnie – TRUE) (nie),

lax – czy można dodać do grupy perspektywę, które jest już w innej grupie (czy można

przenieść perspektywę do grupy)(domyślnie FALSE)(TRUE),

begin

DBMS_REFRESH.MAKE(name => 'RG_GRUPA_01', list => 'studenci_mv, oceny_mv',

next_date => sysdate, interval => 'sysdate + 1/960',

implicit_destroy => FALSE, lax => TRUE);

end;

29. Sprawdź, jakie grupy odświeżania aktualnie istnieją w schemacie użytkownika integracja.

Następnie powtórz eksperyment z p. 25 (zmień identyfikator studenta na 10001).

Strona 51 z 51

Podsumowanie

Zakończyliśmy proces tworzenia i konfigurowania środowiska integracji danych. Udało nam się

połączyć ze sobą systemy zarządzania bazami danych DB2, MySQL i Oracle a także uzyskać dostęp z

SZBD Oracle do danych zgromadzonych w pliku tekstowym.

Jeśli masz jeszcze czas, spróbuj wykonać kilka prostych zestawień danych z wykorzystaniem

zintegrowanych w ćwiczeniu danych.

1. Dla każdego studenta podaj jego średnie ocen w poszczególnych semestrach akademickich

(przy wyliczaniu średniej weź pod uwagę zarówno oceny z przedmiotów jak i z języków

obcych). Jeśli studentowi w danym semestrze akademickim przyznano stypendium

dowolnego rodzaju, podaj informacje o uzyskanym stypendium. Dodatkowo, jeśli studentowi

w danym semestrze przyznano miejsce w akademiku, podaj odpowiednie informacje o jego

zakwaterowaniu.

2. Znajdź 10 najlepszych studentów. Ranking studentów będzie ustalony na podstawie

punktów, które przydzielisz poszczególnym studentom. Zasady przydzielania punktów są

następujące:

a. średnia ocen (z całych studiów):

<2,0; 3,5) – 0 punktów,

<3,5; 4,0) – 10 punktów,

<4,5; 4,5) – 15 punktów,

<4,5; 5,0> – 25 punktów.

b. przyznane stypendia:

c. stypendium za wyniki w nauce – 8 punktów (np. jeśli student uzyskał stypendium za

wyniki w nauce w 4 semestrach, uzyskuje 4*8 = 32 punkty),

d. stypendium sportowe – 10 punktów za każde.

Wyświetl numery albumów wraz z uzyskanymi punktami dla 10 najlepszych studentów.

3. Zbuduj listę przedmiotów, studiowanych przez studentów. Dla każdego przedmiotu podaj

liczbę studentów, którzy go studiowali oraz średnią uzyskanych z tego przedmiotu ocen.

Budując listę przedmiotów weź pod uwagę również oceny, uzyskane przez studentów z

lektoratów.

Documents

Architektury i technologie integracji danychtpd.cs.put.poznan.pl/.../ArchitekturyiTechnologieIntegracjiDanych... · również ręcznie odłączyć się od bazy danych poleceniem disconnect