P

P

R

R

O

O

J

J

E

E

K

K

T

T

O

O

W

W

A

A

N

N

I

I

E

E

D

D

O

O

S

S

T

T

Ę

Ę

P

P

U

U

D

D

O

O

B

B

A

A

Z

Z

Y

Y

D

D

A

A

N

N

Y

Y

C

C

H

H

W

W

A

A

R

R

S

S

T

T

W

W

A

A

T

T

R

R

W

W

A

A

Ł

Ł

O

O

Ś

Ś

C

C

I

I

Dokument techniczny

Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.

Copyright



2001 - 2002 POTIS Software Development Tools

2

Spis Treś ci

Architektura aplikacji wykorzystującej bazę danych. ................................ .................... 3

Rodzaje warstw dostępu do danych. ................................ ................................ ......... 4

Dostęp do danych w klasach biznesowych................................. ................................ .. 5

Klasy dostępu do danych. ................................ ................................ ....................... 6

Deskryptory odwzorowań. ................................ ................................ ...................... 6

Projektowanie warstwy trwałoś ci. ................................ ................................ ............ 7

Samodzielne tworzenie warstwy a zakup................................. ................................ ... 7

Wymagania. ................................ ................................ ................................ ........ 7

Hermetyzacja dostę pu do danych................................. ................................ .............. 8

Minimalizacja ograniczeń w stosowaniu technik obiektowo zorientowanych............................. 8

Rozszerzalność . ................................ ................................ ................................ .... 8

Formułowanie zapytań................................. ................................ ........................... 8

Wsparcie dla czę ściowego odczytu................................. ................................ ............. 9

Mechanizmy opó źnionego odczytu. ................................ ................................ ............. 9

Mechanizmy opó źnionego zapisu. ................................ ................................ ............... 9

Ró żne mechanizmy trwałości. ................................ ................................ ................... 9

Bazy danych od ró żnych dostawcó w. ................................ ................................ ........... 9

Połączenia z wieloma bazami danych w jednej sesji................................. ....................... 10

Literatura. ................................ ................................ ................................ ....... 10

Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.

Copyright



2001 - 2002 POTIS Software Development Tools

3

A

A

r

r

c

c

h

h

i

i

t

t

e

e

k

k

t

t

u

u

r

r

a

a

a

a

p

p

l

l

i

i

k

k

a

a

c

c

j

j

i

i

w

w

y

y

k

k

o

o

r

r

z

z

y

y

s

s

t

t

u

u

j

j

ą

ą

c

c

e

e

j

j

b

b

a

a

z

z

ę

ę

d

d

a

a

n

n

y

y

c

c

h

h

Nowoczesne narzę dzia programistyczne umoż liwiają bardzo szybkie zbudowanie interfejsu

graficznego, czerpiącego dane z bazy relacyjnej. Elementy graficzne, wspó łpracujące z bazą
danych (data-aware controls) ułatwiają prezentację i edycję danych, a komponenty dostę pu do

danych upraszczają kodowanie przetwarzań. Bardzo czę sto za pomocą jednej spó jnej biblioteki klas

moż na operować na ró żnych bazach danych, troszcząc się tylko o specyfikę dialektu SQL,

używanego przez tę czy inną bazę .

Za pomocą technik RAD moż na bardzo szybko budować prototypy albo aplikacje jednorazowe, ale

duże systemy szybko tracą pielę gnowalność . W przypadku dużych systemó w o długim cyklu ż ycia

stosuje się zwykle architekturę tró jwarstwową.

Rys 1. Architektura tró jwarstwowa.

System stworzony zgodnie z zasadami tej architektury składa się z trzech składowych.

a)

Pierwsza warstwa jest odpowiedzialna za kontakt z użytkownikiem i zawiera obiekty interfejsu
graficznego. Jest z natury bardzo silnie związana z określonym środowiskiem

programistycznym.

b)

Druga warstwa składa się z obiektó w związanych z dziedziną problemu, jest wię c
odwzorowaniem modelu poję ciowego, powstałego w wyniku analizy. Składają się na nią obiekty

biznesowe, odwzorowujące poję cia z dziedziny problemu, oraz obiekty sterujące – obiekty

odpowiedzialne za sterowanie przebiegiem przypadkó w użycia.

c)

Trzecia warstwa jest odpowiedzialna za dostę p do danych. Ma zapewniać spó jny i jednolity
dostę p do danych i jest silnie powiązana zaró wno ze środowiskiem programistycznym (albo

standardem dostę pu np. ODBC lub JDBC), jak i bazą danych.

Warstwa prezentacji

Warstwa dziedziny problemu

Warstwa bazy danych

Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.

Copyright



2001 - 2002 POTIS Software Development Tools

4

Dobre rozwiązanie w architekturze tró jwarstwowej charakteryzuje się słabymi związkami, a co za
tym idzie niewielkim wzajemnym wpływem poszczegó lnych warstw. Dzię ki temu zmiany w

schemacie bazy danych są odzwierciedlane tylko w warstwie bazy danych, a zmiany w sposobie

prezentacji nie wpływają ani na warstwę dziedziny problemu, ani na warstwę bazy danych.
Podobnie zmiany w algorytmach biznesowych implikują modyfikacje wyłącznie w warstwie

dziedziny problemu. Najstaranniejsze rozwiązania umożliwiają nawet zmianę technologii

wykorzystywanej przez jedną warstwę (np. zmianę z okienek Windows na strony HTML), bez

wpływu na pozostałe warstwy.

Wyprodukowanie aplikacji o architekturze tró jwarstwowej jest bardziej pracochłonne, niż

wykorzystanie wprost technik RAD, i koncepcyjnie trudniejsze, ale daje kilka istotnych korzyści.

a)

Zaró wno projekt, jak i kod mają konsekwentną, łatwą do czytania strukturę . Każda warstwa

jest skoncentrowana na jednym aspekcie, dzię ki czemu jest prosta. Skutkiem tego:

•

szansa na zakończenie projektu sukcesem jest wię ksza,

•

pielę gnacja produktu jest łatwiejsza.

b)

Zmiany o charakterze technologicznym wymagają przepisania tylko jednej warstwy, wię c są
realne.

R

R

o

o

d

d

z

z

a

a

j

j

e

e

w

w

a

a

r

r

s

s

t

t

w

w

d

d

o

o

s

s

t

t

ę

ę

p

p

u

u

d

d

o

o

d

d

a

a

n

n

y

y

c

c

h

h

Narzę dzia typu RAD nie wspierają architektury tró jwarstwowej. Najłatwiej za ich pomocą tworzyć

aplikacje składające się tylko z warstwy prezentacji i warstwy dostę pu do danych.

Rys 2. Architektura aplikacji typu RAD.

Takie rozwiązanie, jakkolwiek bardzo produktywne, wiąż e ściśle sposó b prezentacji ze strukturą

bazy danych. Nawet drobne zmiany w schemacie muszą być odzwierciedlone w interfejsie

graficznym. Ponieważ nie ma tu miejsca na obiekty biznesowe, pojawiają się zasadnicze problemy

z wykorzystaniem wynikó w analizy. Funkcjonalność obiektó w biznesowych jest implementowana
czę ściowo w bazie danych jako triggery i procedury składowane, a czę ściowo w interfejsie

Warstwa prezentacji

Warstwa bazy danych

Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.

Copyright



2001 - 2002 POTIS Software Development Tools

5

graficznym w kodzie obsługi zdarzeń. Bardziej ambitni projektanci wprowadzają obiekty sterujące,
dzię ki któ rym przebiegi przypadkó w użycia stają się bardziej czytelne.

Rys 3. Aplikacja typu RAD wzbogacona o obiekty sterujące.

Obiekty sterujące mogą też być wykorzystane do implementowania funkcjonalności obiektó w
biznesowych, dzię ki czemu uzyskujemy pewien substytut pełnej warstwy biznesowej.

Niestety problem powiązania warstwy prezentacji ze strukturą bazy danych pozostaje

nierozwiązany. Ró wnież szczątkowa warstwa biznesowa pełna jest zapytań SQL.

D

D

O

O

S

S

T

T

Ę

Ę

P

P

D

D

O

O

D

D

A

A

N

N

Y

Y

C

C

H

H

W

W

K

K

L

L

A

A

S

S

A

A

C

C

H

H

B

B

I

I

Z

Z

N

N

E

E

S

S

O

O

W

W

Y

Y

C

C

H

H

Najprostszym sposobem rozwiązania problemu dostę pu do bazy danych jest umieszczenie kodu

związanego z odczytem i zapisem w klasach biznesowych.

Rys 4. Najprostsze rozwiązanie warstwy dostę pu do danych.

W takim przypadku kod aplikacji powstaje dość szybko, ale funkcjonalność obiektó w biznesowych

zostaje związana ze schematem bazy danych. Zmiany w schemacie bę dą wymagały uwzglę dnienia w

kodzie warstwy dziedziny problemu. Korzyścią jest to, że warstwa prezentacji i obiekty sterujące
są wolne od kodu SQL.

Warstwa prezentacji

Warstwa bazy danych

Warstwa obiektó w

sterujących

Baza danych

S

Klasy
biznesowe

Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.

Copyright



2001 - 2002 POTIS Software Development Tools

6

K

K

L

L

A

A

S

S

Y

Y

D

D

O

O

S

S

T

T

Ę

Ę

P

P

U

U

D

D

O

O

D

D

A

A

N

N

Y

Y

C

C

H

H

Znacznie skuteczniejszym rozwiązaniem jest wprowadzenie klas zarządzających odczytem i

zapisem.

Rys 5. Rozwiązanie z klasami dostę pu do danych.

Odwołania do bazy za pośrednictwem SQL są zgrupowane w warstwie dostę pu do danych, wię c

zmiany w schemacie bazy nie wpływają ani na warstwę prezentacji, ani na warstwę dziedziny

problemu. Niestety bezpośrednio zakodowany SQL wraz ze zmianami schematu może wymagać

dużych modyfikacji.

D

D

E

E

S

S

K

K

R

R

Y

Y

P

P

T

T

O

O

R

R

Y

Y

O

O

D

D

W

W

Z

Z

O

O

R

R

O

O

W

W

A

A

Ń

Ń

Rys 6. Warstwa trwałości z deskryptorami odwzorowań.

Najbardziej zaawansowanym rozwiązaniem jest warstwa trwałości bez rę cznie wprowadzonego

kodu SQL Taka warstwa zawiera opisy odwzorowań pomię dzy klasami biznesowymi i tabelami bazy
relacyjnej i generuje kod SQL na ich podstawie. Pisanie kodu transformującego jest znacznie

łatwiejsze, niż w dwó ch poprzednich przypadkach (ze wzglę du na jego deklaratywny charakter), a

wszelkie zmiany w schemacie bazy mogą być łatwo uwzglę dniane. W szczegó lnych przypadkach
opisy odwzorowań mogą być przechowywane w zewnę trznych plikach, zwykle stosuje się do tego

Baza danych

S

Klasy
biznesowe

Klasy
dostę pu do
danych

Klasy
biznesowe

Baza danych

Warstwa

trwałości z

deskryptorami

odwzorowań

S

Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.

Copyright



2001 - 2002 POTIS Software Development Tools

7

format XML. Narzę dzia komercyjne, takie jak TopLink oferują wygodne edytory odwzorowań
(Mapping WorkBench).

P

P

r

r

o

o

j

j

e

e

k

k

t

t

o

o

w

w

a

a

n

n

i

i

e

e

w

w

a

a

r

r

s

s

t

t

w

w

y

y

t

t

r

r

w

w

a

a

ł

ł

o

o

ś

ś

c

c

i

i

S

S

A

A

M

M

O

O

D

D

Z

Z

I

I

E

E

L

L

N

N

E

E

T

T

W

W

O

O

R

R

Z

Z

E

E

N

N

I

I

E

E

W

W

A

A

R

R

S

S

T

T

W

W

Y

Y

A

A

Z

Z

A

A

K

K

U

U

P

P

Zbudowanie dobrej warstwy trwałości jest trudnym zadaniem. Niemniej trudne jest jej

pielę gnowanie. Ponieważ ma ona stanowić tylko oprogramowanie narzę dziowe, zwykle nie bę dzie
tak rozwinię ta jak produkty komercyjne. Ponadto samodzielne stworzenie warstwy stanowi pewne

ryzyko. Biorąc to wszystko pod uwagę warto sprawdzić , czy nie dałoby się kupić narzę dzia do

tworzenia warstwy trwałości. Na rynku jest dość dużo tego typu produktó w działających w ję zyku

Java, np.:

•

VBSF (Object Matter),

•

Blend (Sun Microsystems),

•

TopLink (WebGain),

oraz produkty public domain, jak np.:

•

Osage,

•

Castor.

Warto jednak najpierw zorientować się , czego oczekujemy od warstwy.

W

W

Y

Y

M

M

A

A

G

G

A

A

N

N

I

I

A

A

Przed przystąpieniem do projektu należ y określić potrzeby, któ re ma spełniać warstwa trwałości.

Oczywiście waż ne jest, żeby projekt nie przekraczał możliwości zespołu, budżetu itd. Wymagania

powinny być na tyle duże, żeby zaspokajać oczekiwania użytkownikó w warstwy, ale na tyle małe,
żeby twó rcy byli w stanie ją dostarczyć w wyznaczonym czasie. Ró ż ne typy aplikacji stawiają inne

wymagania warstwie trwałości. Dla aplikacji związanych z prowadzeniem przedsię biorstwa waż na

bę dzie łatwość wprowadzania zmian w warstwie dziedziny problemu, podczas gdy w przypadku
repozytorió w narzę dzi CASE istotniejsze bę dzie dobre rozwiązanie przetwarzania złożonych struktur

danych. Niektó re systemy muszą być tworzone z założeniem, że każ de wdroż enie moż e wymagać
użycia innej bazy danych, w innych przypadkach wiadomo, ż e bę dzie to jedna baza i nigdy się nie

zmieni. Dlatego też poniższa lista zawiera możliwie duż y zbió r wymagań, czę sto ze wskazó wkami,

kiedy mogą być istotne. W niektó rych przypadkach podany jest rodzaj wymagania z listą rozwiązań
do wyboru.

Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.

Copyright



2001 - 2002 POTIS Software Development Tools

8

H

H

e

e

r

r

m

m

e

e

t

t

y

y

z

z

a

a

c

c

j

j

a

a

d

d

o

o

s

s

t

t

ę

ę

p

p

u

u

d

d

o

o

d

d

a

a

n

n

y

y

c

c

h

h

Podstawowym zadaniem warstwy trwałości jest ukrycie przed pozostałymi warstwami

szczegó łó w dotyczących dostę pu do danych. W zależności od stopnia złożoności
tworzonego oprogramowania wymagania związane z hermetyzacją dostę pu mogą być

ró żne.

a) W najprostszym przypadku hermetyzacja polega na tym, że użytkownik warstwy

wywołuje tylko metody obiektó w trwałych Retrieve, Save, Delete. Nie zna ani

położenia fizycznych danych, ani sposobu zapisu.

b) Bardziej ambitne rozwiązanie to hermetyzacja rozumiana jako przezroczystość.

Użytkownik takiej warstwy nie wie nawet, kiedy i czy w ogó le coś zapisuje, bądź

odczytuje. Oczywiście pełna przezroczystość jest nieosiągalna ze wzglę du na
wielodostę p (a wię c transakcje, blokowanie danych, odświeżanie), ale można

uzyskać dobre przybliżenie. W moim odczuciu wystarczającym przybliżeniem jest
przezroczystość algorytmiczna, w przypadku, któ rej w kodzie związanym z

dziedziną problemu pojawiają się pewne elementy dotyczące bazy danych, ale

nie wpływają na przebieg algorytmó w.

M

M

i

i

n

n

i

i

m

m

a

a

l

l

i

i

z

z

a

a

c

c

j

j

a

a

o

o

g

g

r

r

a

a

n

n

i

i

c

c

z

z

e

e

ń

ń

w

w

s

s

t

t

o

o

s

s

o

o

w

w

a

a

n

n

i

i

u

u

t

t

e

e

c

c

h

h

n

n

i

i

k

k

o

o

b

b

i

i

e

e

k

k

t

t

o

o

w

w

o

o

z

z

o

o

r

r

i

i

e

e

n

n

t

t

o

o

w

w

a

a

n

n

y

y

c

c

h

h

Oprogramowanie realizujące warstwę dostę pu do danych nie powinno zmuszać do

dostosowywania obiektó w biznesowych do potrzeb relacyjnej bazy danych, zwłaszcza,
jeśli chodzi o dziedziczenie i związki.

R

R

o

o

z

z

s

s

z

z

e

e

r

r

z

z

a

a

l

l

n

n

o

o

ś

ś

ć

ć

Warstwa trwałości powinna być tak skonstruowana, żeby łatwo było dodawać nowe klasy

do mechanizmu trwałości. Poziom rozszerzalności zależy w zasadzie od rodzaju warstwy
trwałości. W przypadku warstwy dostę pu z deskryptorami odwzorowań wystarczy dopisać

odpowiednie deskryptory.

F

F

o

o

r

r

m

m

u

u

ł

ł

o

o

w

w

a

a

n

n

i

i

e

e

z

z

a

a

p

p

y

y

t

t

a

a

ń

ń

Warstwa powinna umożliwiać zadawanie pytań, i to nie bezpośrednio w SQL, tylko w
kategoriach obiektó w. W zależności od tworzonego systemu mogą być potrzebne proste

zapytania o wartości atrybutó w, albo bardzo złożone z odwołaniem do obiektó w

powiązanych, z operatorami sprawdzania, czy element należy do kolekcji itd. W

ekstremalnym przypadku może wystąpić potrzeba zaimplementowania OQL. Dobrze

Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.

Copyright



2001 - 2002 POTIS Software Development Tools

9

byłoby uwzglę dnić możliwość formułowania podzapytań na kolekcjach, zwłaszcza na
rolach.

Głó wna trudność polega jednak na tym, ż e trzeba wprowadzić mechanizm
przeszukiwania pod kątem zapytania obiektó w znajdujących się w pamię ci operacyjnej.

W

W

s

s

p

p

a

a

r

r

c

c

i

i

e

e

d

d

l

l

a

a

c

c

z

z

ę

ę

ś

ś

c

c

i

i

o

o

w

w

e

e

g

g

o

o

o

o

d

d

c

c

z

z

y

y

t

t

u

u

Dość czę sto się zdarza, że nie chcemy odczytywać wszystkich atrybutó w obiektu, a tylko

takie, któ re mają być w danym momencie wyświetlone. W przypadku duż ych zapytań
taki czę ściowy odczyt moż e dać duży zysk czasowy i zmniejszyć zapotrzebowanie na

pamię ć .

M

M

e

e

c

c

h

h

a

a

n

n

i

i

z

z

m

m

y

y

o

o

p

p

ó

ó

ź

ź

n

n

i

i

o

o

n

n

e

e

g

g

o

o

o

o

d

d

c

c

z

z

y

y

t

t

u

u

Podczas odczytywania obiektu trwałego odczytywanie obiektó w powiązanych z nim

powinno być opcjonalne. Żeby można było odczytać je pó źniej trzeba znaleźć jakiś

sposó b na reprezentowanie ró l.

M

M

e

e

c

c

h

h

a

a

n

n

i

i

z

z

m

m

y

y

o

o

p

p

ó

ó

ź

ź

n

n

i

i

o

o

n

n

e

e

g

g

o

o

z

z

a

a

p

p

i

i

s

s

u

u

W przypadku, gdy obiekty trwałe są zapisywane jawnie, przez wywołanie metody Save,

algorytmy w warstwie biznesowej zależą od kolejności zapisu. Aby zapobiec tego

rodzaju wpływowi należy zapisywać obiekty trwałe w jednym kroku.

R

R

ó

ó

ż

ż

n

n

e

e

m

m

e

e

c

c

h

h

a

a

n

n

i

i

z

z

m

m

y

y

t

t

r

r

w

w

a

a

ł

ł

o

o

ś

ś

c

c

i

i

W pewnych sytuacjach moż e zachodzić potrzeba zapisywania obiektó w trwałych w
bardzo ró żnorodny sposó b. Nie tylko w bazach relacyjnych, ale w obiektowo-

relacyjnych, obiektowych, w plikach tekstowych, plikach ISAM lub VSAM itd.

B

B

a

a

z

z

y

y

d

d

a

a

n

n

y

y

c

c

h

h

o

o

d

d

r

r

ó

ó

ż

ż

n

n

y

y

c

c

h

h

d

d

o

o

s

s

t

t

a

a

w

w

c

c

ó

ó

w

w

Ró żne bazy relacyjne stosują ró żne dialekty SQL. Bardzo czę sto konstrukcje w jednej

bazie optymalne, w innej są bardzo nieefektywne. Jeśli tworzony system ma działać
skutecznie z ró żnymi bazami danych, trzeba to uwzglę dnić odpowiednio wcześnie.

Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.

Copyright



2001 - 2002 POTIS Software Development Tools

10

P

P

o

o

ł

ł

ą

ą

c

c

z

z

e

e

n

n

i

i

a

a

z

z

w

w

i

i

e

e

l

l

o

o

m

m

a

a

b

b

a

a

z

z

a

a

m

m

i

i

d

d

a

a

n

n

y

y

c

c

h

h

w

w

j

j

e

e

d

d

n

n

e

e

j

j

s

s

e

e

s

s

j

j

i

i

Wię kszość organizacji posiada wię cej niż jedną bazę danych, bardzo czę sto poszczegó lne

bazy danych są od ró żnych dostawcó w. Dobra warstwa trwałości powinna umożliwiać
obsługiwanie wielu połączeń na raz.

L

L

i

i

t

t

e

e

r

r

a

a

t

t

u

u

r

r

a

a

•

Jacobson I, Object Oriented Software Engineering, A Use Case Driven Approach, Addison-
Wesley 1994.

•

Ambler S.W, The Design of a Robust Persistence Layer For Relational Databases,

http://www.AmbySoft.com/persistenceLayer.pdf

.

•

Keller W, Object-Relational Access Layers,

http://ourworld.compuserve.com/homepages/WolfgangWKeller

.