Rozdział monografii: `Bazy Danych: Nowe Technologie`, Kozielski S

Transkrypt

Rozdział monografii: 'Bazy Danych: Nowe Technologie', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2007
Rozdział 31
w
Strategie integracji relacyjnych baz danych
w systemach klasy ERP na przykładzie mySAP ERP
w
1 Wstęp
da
.b
w
Streszczenie. Krytycznym elementem każdego systemu klasy ERP
(Enterprise Resource Planning) jest centralne repozytorium danych. Rolę tę
pełni relacyjna baza danych. Stanowi ona zintegrowany zbiór danych
dotyczących całej organizacji gospodarczej. Celem niniejszego opracowania
jest zdefiniowanie i porównanie strategii integracji relacyjnych baz danych
w ramach systemów ERP oraz wskazanie ich silnych i słabych stron.
Strategie integracji baz danych z systemami klasy ERP zostały sformułowane
na podstawie analizy sposobu funkcjonowania systemu mySAP ERP firmy
SAP – światowego lidera dostawców systemów informatycznych
wspierających działalność organizacji.
pl
s.
System mySAP ERP1 jest zintegrowanym systemem informatycznym klasy ERP, czyli
„gotowym do implementacji, zintegrowanym zbiorem modułów (aplikacji) obsługującym
wszystkie biznesowe funkcje przedsiębiorstwa i posiadającym możliwość dynamicznej
konfiguracji, dzięki czemu zapewnia funkcjonalność pokrywającą specyficzne wymagania
danej organizacji. ERP umożliwia przedsiębiorstwom przetwarzanie danych w czasie
rzeczywistym w zintegrowanym, zorientowanym na procesy i kierowanym informacjami
środowisku”[4]. System mySAP ERP jest częścią większego zbioru rozwiązań
informatycznych o nazwie mySAP Business Suite2.
W skład systemu mySAP ERP wchodzą następujące funkcjonalności podstawowe [1]:
1) Logistyka:
a) gospodarka materiałowa – pozwala na ustalanie zapotrzebowania na materiały,
tworzenie wewnętrznego polecenia zakupu, zarządzanie dostawcami,
wystawianie zlecenia zakupu, obsługa fakturowania,
b) produkcja – umożliwia planowanie oraz techniczne przygotowanie produkcji,
planowanie zdolności produkcyjnych, przekazanie wyrobów gotowych do
magazynu,
1
Bieżąca wersja systemu mySAP ERP nosi nazwę mySAP ERP 2005.
W skład mySAP Business Suite oprócz mySAP ERP wchodzą: mySAP CRM, mySAP PLM,
mySAP SCM oraz mySAP SRM.
2
Piotr Mielcarek
Uniwersytet Gdański, Katedra Informatyki Ekonomicznej, ul. Piaskowa 9, 81-824 Sopot, Polska
email: [email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2007
P. Mielcarek
w
c) sprzedaż i dystrybucja – wspomaga następujące funkcje: obsługa zapytań
ofertowych oraz tworzenie zleceń sprzedaży, spedycja towarów,
d) zarządzanie jakością.
2) Rachunkowość:
a) rachunkowość finansowa – funkcja księgi głównej, odbiorców, dostawców,
środków trwałych,
b) zarządzanie finansami – obsługa transakcji, kont bankowych, analiza ryzyka
kredytowego,
c) controlling – wspomaganie controllingu strategicznego oraz operatywnego,
d) zarządzanie inwestycjami.
3) Zarządzanie Kadrami:
a) gospodarka kadrowa – wspomaga ewidencję pracowników, ewidencję umów,
b) zarządzanie czasem pracy – ewidencja i statystyki czasu pracy,
c) rozliczenie listy płac – naliczanie wynagrodzeń, rozliczenia podatkowe
i ubezpieczeniowe,
d) zarządzanie podróżami służbowymi – ewidencja i rozliczanie kosztów podróży
służbowych.
w
w
2 Architektura systemu mySAP ERP
da
.b
pl
s.
System mySAP ERP jest systemem o architekturze trójwarstwowej (three-layer
architecture), wyodrębniono następujące warstwy:
− warstwa prezentacji (presentation layer),
− warstwa aplikacji (application layer),
− warstwa danych (data layer).
Warstwy te mogą być rozlokowane na:
1) jednym węźle (one-tier) – stosowane w przypadku systemów demonstracyjnych, nie
jest to rozwiązanie o charakterze produkcyjnym,
2) dwóch węzłach (two-tier) – jest to rozwiązanie odpowiednie dla systemów
o niewielkiej ilości użytkowników końcowych (przyjmuje się do 100
użytkowników), warstwa danych oraz warstwa aplikacji są umieszczone na jednym
węźle fizycznym (serwerze) natomiast warstwa prezentacji stanowi oddzielny węzeł
fizyczny (warstwa prezentacji może zostać rozmieszczona na wielu węzłach
fizycznych).
3) trzech węzłach (three-tier) – sposób rozlokowania polegający na rozmieszczeniu
każdej z warstw systemu na oddzielnych węzłach fizycznych (warstwa aplikacji
może zostać rozmieszczona na wielu węzłach fizycznych), wariant ten jest
stosowany w przypadku systemów produkcyjnych o dużej ilości użytkowników
końcowych.
4) wielu węzłach (multi-tier) – rozwiązanie polegające na wprowadzeniu do
konfiguracji trójwęzłowej dodatkowej warstwy pośredniczącej (middleware), która
może być rozlokowana na jednym bądź wielu węzłach.
Najczęściej spotykaną konfiguracją przestrzenną systemu jest rozlokowanie na trzech
węzłach [5] (rys. 1), zatem w dalszej części tego opracowania omawiany będzie wyłącznie
ten wariant.
318
Strategie integracji relacyjnych baz danych w systemach klasy ERP na przykładzie mySAP ERP
Użytkownicy końcowi
w
Warstwa Prezentacji
SAPGUI
w
Warstwa aplikacji
w
Planista
Kolejkowanie
da
.b
Procesy
robocze
Warstwa danych
Relacyjna
Baza
Danych
Rys. 1. Architektura systemu mySAP ERP
pl
s.
2.1 Warstwa prezentacji
Warstwa prezentacji zwana inaczej warstwą interfejsu użytkownika ma za zadanie
zapewnienie interakcji między użytkownikiem końcowym a system (wyświetlanie
formularzy, komunikacja z warstwą aplikacji). mySAP ERP wykorzystuje cienkiego
klienta (thin client) o nazwie SAPGUI (SAP Graphical User Interface). Dostępne są
dystrybucje tego oprogramowania na systemy operacyjne: Windows (SAPGUI for
Windows), Linux, Unix, Mac OS X (przenośność zapewniono dzięki użyciu języka Java –
SAPGUI for Java).
2.2 Warstwa aplikacji
Warstwa aplikacji odpowiedzialna jest za obsługę logiki biznesowej oraz realizację
następujących funkcji:
− przetwarzanie transakcji użytkownika (wykonywanie programów ABAP
uruchamianych przez użytkownika),
319
P. Mielcarek
w
− komunikacja z warstwą danych (pobieranie danych niezbędnych do realizacji zadań
zleconych przez użytkownika końcowego oraz przesyłanie danych wymagających
aktualizacji), warstwa prezentacji nie ma bezpośredniego dostępu do warstwy
danych.
Generalizując zadaniem warstwy aplikacji jest świadczenie usług na rzecz warstwy
prezentacji (użytkownika końcowego), dane niezbędne do realizacji tych zadań pobierane
są z warstwy danych.
2.3 Warstwa danych
3 Baza danych systemowych
3.1 Słownik danych systemowych
pl
s.
da
.b
w
w
Warstwa danych zapewnia trwałość danym systemowym, zaimplementowana jest za
pomocą relacyjnego systemu baz danych. Większość informacji wyświetlanych przez
warstwę prezentacji utrwalona jest w warstwie danych [3]. Baza danych zawiera
następujące kategorie danych:
− dane wprowadzone przez użytkowników (np. dane dostawców, odbiorców,
dokumenty księgowe),
− kod źródłowy programów (w języku ABAP3),
− Słownik danych systemowych (słownik ABAP),
− formatki ekranowe,
− menu systemowe,
− teksty komunikatów systemowych,
− ustawienia użytkowników systemowych (dane związane z personalizacją),
− definicje drukarek oraz serwerów wydruku,
− statystyki systemowe,
− dokumentację.
Dane przechowane w bazie danych są niezbędne do poprawnego funkcjonowania jednostki
gospodarczej. Mając to na uwadze można stwierdzić, iż system baz danych stanowi serce
systemu mySAP ERP a także każdego innego systemu ERP.
mySAP ERP umożliwia wykorzystanie następujących systemów baz danych:
− Oracle
− Microsoft SQL Server
− IBM DB2,
− Informix,
− MaxDB.
Słownik danych systemowych zwany inaczej słownikiem danych ABAP (ABAP data
dictionary) lub słownikiem ABAP (ABAP dictionary) stanowi zbiór definicji (metadanych)
wszystkich danych zdefiniowanych w systemie takich jak:
3
Advanced Business Application Programming (ABAP) – język programowania czwartej generacji
stworzonym przez firmę SAP. Większość funkcjonalności systemu zaimplementowana jest w języku
ABAP. Użytkownik ma możliwość rozszerzania funkcjonalności korzystając z tego języka.
320
w
− tabele systemowe (ponad 30000) oraz ich struktury,
− typy danych oraz typy danych użytkownika,
− struktury (structures) oraz widoki danych (views),
− obiekty blokad (lock objects) oraz dozwolone operacje na obiektach,
− indeksy,
− związki między tabelami.
Słownik ABAP stanowi zatem dodatkową warstwę abstrakcji nad bazą danych. System
mySAP ERP operuje na wewnętrznych reprezentacjach obiektów systemowych
(zdefiniowanych w słowniku ABAP) nie zaś bezpośrednio na strukturach (tabelach)
zdefiniowanych w bazie danych. Słownik danych systemowych zapewnia spójność,
integralność oraz bezpieczeństwo danych.
w
3.2 Klasyfikacja logicznych struktur danych systemowych
da
.b
w
Podstawową logiczną strukturą danych w systemie mySAP ERP jest tabela. Ze względu na
sposób odwzorowania w relacyjnej bazie danych wyróżnia się trzy rodzaje tabel
systemowych (tab. 1):
1) tabele transparentne (transparent tables) – tabele zdefiniowane w słowniku ABAP,
reprezentowane w bazie danych przez pojedyncze relacje,
2) tabele sumaryczne (pooled tables) – tabele zdefiniowane w słowniku ABAP, dane
z kilku tabel sumarycznych reprezentowane są w bazie danych przez pojedynczą
relację,
3) klastry (cluster tables) – tabele zdefiniowane w słowniku ABAP, dane pochodzące
z kilku klastrów przechowywane są w bazie danych w pojedynczej relacji.
Tabela 1. Zestawienie logicznych struktur danych systemowych
Struktura
Odwzorowanie
w bazie danych
Możliwość dostępu
do struktury
bezpośrednio z bazy
danych
Przykłady
Tabela sumaryczna
Klaster
1:1
jednej tabeli
transparentnej
odpowiada jedna
tabela w bazie danych
o takiej samej nazwie
N:1
n tabelom
sumarycznym
odpowiada jedna
tabela w bazie
danych
N:1
n klastrom
odpowiada jedna
tabela w bazie
danych
Tożsame
Różne
Różne
Nie
Nie
M_DEBI,
M_MCBM
M_MCEA,
BSEC, BSEG
Tak
VBAP, VBAK,
COEP
pl
s.
Schemat struktury
systemowej
oraz struktury
w bazie danych
Tabela transparentna
321
P. Mielcarek
4 Komunikacja z bazą danych
4.1 Sposoby dostępu do danych
w
Proces realizacji zapytania (żądania) użytkownika - dostępu do danych zawartych
w systemie, modyfikacji tych danych oraz definiowania nowych danych jest realizowany
przy wykorzystaniu graficznego interfejsu użytkownika (SAPGUI), który jest
zainstalowany na komputerach użytkowników końcowych. Żądania są przesyłane przy
wykorzystaniu sieci komputerowych oraz zoptymalizowanego protokołu DIAG do serwera
aplikacji, następnie proces planista przydziela wolny proces roboczy lub gdy nie jest to
możliwe (np ze względu na brak wolnych procesów roboczych) umieszcza żądanie na liście
zadań oczekujących na realizację (kolejkuje żądanie). W sytuacji gdy występuje jeden
lub więcej wolnych procesów roboczych planista przydziela proces roboczy do zadania
oczekującego na realizację i takie zadanie usuwane jest z kolejki. Proces roboczy jest
usługą systemową, której zadaniem jest wykonanie niezbędnych operacji na danych w celu
zwrócenia informacji do komputera użytkownika końcowego. Dane niezbędne do realizacji
tych operacji proces roboczy uzyskuje z bazy danych. Można powiedzieć, że procesy
robocze w systemie SAP R/3 mają charakter współdzielony(nie są to procesy o charakterze
dedykowanym) – po wykonaniu żądań danego użytkownika proces roboczy nie jest
dealokowany ale oczekuje na przydział zadań przez planistę. Każdy proces roboczy składa
się z następujących elementów:
− organizator zadań (task handler) – zarządza (tworzy, usuwa) kontekstem sesji
użytkownika (z ang. user session context) na początku i końcu każdego kroku
dialogu (dialog step). Komunikuje się z planistą i aktywuje interpreter dialogu (znany
także jako dynpro processor) i procesor ABAP jeśli są wymagane do wykonania
danego zadania,
− interpreter dialogu (dialog interpreter, dynpro processor) – wykonuje i interpretuje
logikę formatek systemu R/3,
− procesor ABAP (ABAP processor) – wykonuje programy ABAP,
− interfejs bazy danych (database interface) – umożliwia komunikację procesu
roboczego z bazą danych.
pl
s.
da
.b
w
w
Rys. 2. Struktura procesu roboczego
Po wykonaniu żądania przez proces roboczy rezultaty są zwracane do planisty, który
przesyła je do komputera użytkownika końcowego. Przepływ danych między warstwą
prezentacji a serwerem aplikacji jest w systemie SAP R/3 zoptymalizowany – zazwyczaj
wielkość bloku danych przesyłanego od planisty do SAPGUI nie przekracza 2KB.
322
w
Procesy robocze w celu realizacji przydzielonych im zadań potrzebują następujących
zasobów:
− danych,
− kodu aplikacji,
− struktur logicznych zdefiniowanych w słowniku ABAP.
Wszystkie te elementy znajdują się w warstwie danych. Interfejs bazy danych komunikuje
się z bazą danych za pomocą języka SQL. Dostępne są dwa warianty użycia języka SQL.
1) Implementacja języka SQL systemu baz danych zastosowanego w warstwie danych
(native SQL, znany wcześniej pod nazwą EXEC-SQL) – pozwala programom ABAP
uzyskać bezpośredni dostęp do danych zawartych w bazie danych (nie wymaga
użycia słownika danych ABAP).
pl
s.
da
.b
w
w
Rys. 3. Użycie native SQL
2) Open SQL (znany wcześniej pod nazwą SAP-SQL) stanowi implementację języka
SQL stworzoną przez firmę SAP w oparciu o standard SQL-92 (entry level).
Polecenia Open SQL w ramach programów ABAP tłumaczone są przez interfejs
bazy danych na dialekt SQL danego systemu baz danych. Open SQL umożliwia
operowanie wyłącznie na strukturach danych zdefiniowanych w słowniku ABAP.
Podczas interpretacji poleceń Open SQL interfejs bazy danych dokonuje sprawdzenia
poprawności składni poleceń oraz optymalizuje plan realizacji zapytań
wykorzystując bufor systemowy.
323
P. Mielcarek
w
da
.b
w
w
Rys. 3. Użycie open SQL
4.2 Porównanie sposobów dostępu do danych
pl
s.
Użycie w programach ABAP native SQL wiąże się, jak dowodzi J. Doppelhammer (et al.)
[2] z lepszą wydajnością (szybszym czasem realizacji) zapytań niż w przypadku użycia
kodu napisanego w open SQL. Wynika to z braku konieczności translacji zapytań, co jest
konieczne w przypadku użycia open SQL. Użycie w kodzie programów native SQL wiąże
się z możliwością wykorzystania specyficznych funkcji języka SQL danego systemu baz
danych. Bezpośredni dostęp do bazy danych wiąże się z potencjalnym zagrożeniem
bezpieczeństwa i integralności danych, która jest zapewniona przez słownik danych
systemowych. Za pomocą native SQL można uzyskać dostęp wyłącznie do tych struktur
danych systemowych, których schemat w słowniku ABAP i w bazie danych jest taki sam.
Implementacja aplikacji z wykorzystaniem native SQL wiąże się z potencjalnym
ograniczeniem przenośności aplikacji ze względu na specyficzne elementy składni języka
SQL (uzależnienie od konkretnego systemu baz danych). Implementacja programów ABAP
oparta na open SQL zapewnia oprogramowaniu przenaszalność, umożliwia dostęp do
wszystkich struktur danych systemowych przy jednoczesnym zachowaniu bezpieczeństwa
danych. Wybór ten wiąże się jednak z dłuższym czasem realizacji zapytań niż w przypadku
użycia języka SQL danego systemu baz danych.
324
Tabela 2. Porównanie sposobów dostępu do danych
Native SQL
Sposób
-
w
Zalety
-
szybsza realizacja
zapytań niż open SQL
bogactwo składni
języka
-
-
w
-
ogranicza lub eliminuje
przenośność aplikacji
brak możliwości
dostępu do klastrów
oraz tabel
sumarycznych
wymaga wiedzy
eksperckiej na temat
struktury danych
systemowych
stwarza potencjalne
zagrożenie
bezpieczeństwa
i integralności danych
-
-
pełna przenośność
aplikacji
zapewnienie
bezpieczeństwa
i integralności danych
umożliwia dostęp do
wszystkich struktur
danych systemowych
dłuższy czas realizacji
zapytań niż
w przypadku
native SQL
ograniczone możliwości
wykorzystania
specyficznych funkcji
danego systemu baz
danych
da
.b
w
Wady
Open SQL
-
-
5 Strategie integracji baz danych w systemach ERP
pl
s.
Na podstawie rozwiązań zastosowanych w systemie mySAP ERP możliwe jest
zdefiniowanie trzech ogólnych strategii integracji relacyjnych baz danych w ramach
systemów ERP (tab. 3).
1) Bezpośrednia integracja strukturalna – wiąże się z silnym powiązaniem systemu
ERP oraz systemu baz danych. Umożliwia korzystanie z wszystkich funkcji danego
systemu baz danych, zapewniając przy tym dużą wydajność. Charakteryzuje się
jednak brakiem przenośności aplikacji (uzależnienie od konkretnego systemu baz
danych).
2) Pośrednia integracja strukturalna – polega na wprowadzeniu dodatkowej abstrakcji
systemowej – elementu pośredniczącego (interfejsu) między systemem ERP
a relacyjną bazą danych oraz zdefiniowaniu języka zapytań na potrzeby aplikacji
wchodzących w skład systemu ERP. Rozwiązanie to nie pozwala na pełne
wykorzystanie możliwości danego systemu baz danych. Charakteryzuje się pełną
przenośnością aplikacji (możliwość współpracy z różnymi systemami baz danych).
325
P. Mielcarek
w
Wydajność komunikacji systemu z bazą danych jest mniejsza niż w przypadku
pierwszej strategii.
3) Hybrydowa integracja strukturalna – polega na wykorzystaniu silnych stron dwóch
powyższych strategii. Dostęp do bazy danych może być realizowany na dwa
sposoby, możliwe jest dzięki temu uzyskanie satysfakcjonującego poziomu
wydajności przy jednoczesnej możliwości zachowania przenośności aplikacji.
Przykładem zastosowania tej strategii jest system mySAP ERP.
Tabela 3. Strategie integracji baz danych w systemach ERP
Strategia
Silne strony
w
Bezpośrednia
integracja strukturalna
-
-
w
-
Słabe strony
zapewnia najwyższą
wydajność komunikacji z
bazą danych
umożliwia pełne
wykorzystanie funkcji
danego systemu baz
danych
prostota implementacyjna
rozwiązania
-
brak przenośności
aplikacji (silne
uzależnienie od
danego systemu baz
danych)
da
.b
Pośrednia integracja
strukturalna
-
możliwość zapewnienia
pełnej przenośność
aplikacji
-
-
6 Podsumowanie
-
możliwość zapewnienia
przenośności aplikacji
-
duża złożoność
implementacyjna
rozwiązania
pl
s.
Hybrydowa integracja
strukturalna
zapewnia najniższą
wydajność
komunikacji z bazą
danych
ograniczone
możliwości
wykorzystania
funkcjonalności
systemu baz danych
Dobór strategii integracji baz danych w systemach ERP jest zadaniem istotnym zarówno
z punktu widzenia klienta jak i producenta systemu ERP. Dla organizacji gospodarczej
(klienta) jest on pomocny przy doborze systemu ERP a także dopasowaniu systemu tej
klasy do istniejącej infrastruktury technicznej (systemów baz danych). Dla producentów
systemów ERP wybór strategii jest czynnikiem niezbędnym do planowania strategii
rozwoju produktu a także określenia strategii współpracy z dostawcami systemów baz
danych.
326
Na podstawie analizy sposobu komunikacji z bazą danych w systemie mySAP ERP
sformułowano trzy możliwe strategie integracji baz danych w systemach ERP
oraz wskazano ich silne i słabe strony.
Literatura
w
1.
2.
3.
4.
5.
pl
s.
da
.b
w
w
Bytniewski A.: Architektura zintegrowanego systemu informatycznego zarządzania.
Wydawnictwo AE, Wrocław 2005.
Doppelhammer J., Hoppler T., Kemper A., Kossman D.: Database Performance in the Real
World. ACM SIGMOD international conference on Management, Tucson 1997.
Hernandez H., Martinez M., Keogh J.: SAP R/3 Handbook. McGraw-Hill Osborne Media,
Nowy Jork 2005.
Kale V.: SAP R/3. Przewodnik dla menadżerów. Wydawnictwo Helion, Gliwice 2001.
Missbach M., Hoffmann U.: SAP Hardware Solutions. Prentince Hall, Upper Saddle River 2000.
327
w
pl
s.
da
.b
w
w

Rozdział monografii: `Bazy Danych: Nowe Technologie`, Kozielski S

Transkrypt

Podobne dokumenty

MS POS- Programista

referencje - SIMPLE SA

Program do zarządzania ERP/MIS

Systemy ERP – profesjonalne planowanie zasobów firmy

Konsultant ds. Wdrożeń Systemu ERP/Programista Warszawa

erp – optymalne narzędzie

Programista SQL, PL/SQL, PHP - Polisa

L`Opéra National de Paris bascule sur un PGI pour sa mise en co

Kierownik Projektu Warszawa

Project Manager ERP Pracodawca: SMART-HR