Projektowanie rozproszonych baz danych

przy użyciu Sybase PowerDesigner

Instytut Systemów Informatycznych, Wydział Cybernetyki, Wojskowa Akademia Techniczna

Marcin Dąbkiewicz, Jarosław Koszela

Spis treści

1.

Wprowadzenie i cel zadania ............................................................................................................ 1

2.

Tworzenie modelu danych przy użyciu PowerDesigner .................................................................. 2

a.

Model konceptualny danych ....................................................................................................... 2

b. Model fizyczny danych .............................................................................................................. 16

3.

Model rozproszonej bazy danych .................................................................................................. 24

Spis rysunków ........................................................................................................................................ 42

1. Wprowadzenie i cel zadania

PowerDesigner to narzędzie typu CASE (Computer Aided Software/Systems Engineering)

zawierające zestaw narzędzi do modelowania – dedykowane zarówno informatykom, jak i analitykom
biznesowym. Łączy w sobie funkcje szczególnie ważne dla przedsiębiorstw, które dostosowując się do
wymagao rynku, zmieniają i rozwijają infrastrukturę IT. PowerDesigner zaspokaja te potrzeby,
umożliwiając szybsze wykonanie zadao projektowych. Kompleksowośd PowerDesignera pozwala użyd
jednego narzędzia do analizy, modelowania struktur baz danych, definicji struktur XML czy
projektowania obiektowego. Niewątpliwą zaletą tego narzędzia i jego przewagą nad podobnymi
narzędziami dostępnymi na rynku (szczególnie z punktu widzenia praktyków) jest położenie dużego
nacisku na efektywne i kompleksowe „przejście” od opisu modelowego systemu do jego
implementacji.

No dobrze – takie było założenie twórców tego narzędzia, ale czy im się to rzeczywiście udało? Na

prostym przykładzie zobaczymy czy utworzenie modelu rozproszonej bazy danych z wraz replikacją i
konfiguracją wszystkich tych elementów jest rzeczywiście takie proste jak zakładano. Naszym celem

jest zaprojektowanie i implementacja baz danych systemu „sklepowego” (w bardzo uproszczonej
wersji) – bazy centralnej, bazy/baz oddziałów wraz z określeniem mechanizmu replikacji danych w
celu zsynchronizowania danych bazy centralnej z bazami oddziałów. Spróbujemy zamodelowad
uproszczony model sklepu oraz jego oddziału i replikację danych pomiędzy tymi modelami.

Zanim rozpoczniemy modelowanie struktury danych naszej bazy należy przyjąd pewne założenia

projektowe dla naszej bazy danych:



sklep przechowuje informacje o klientach i pracownikach,



pracownik sklepu wystawia klientowi fakturę na zakupiony towar,



cena produktu może się zmieniad,



sklep nie prowadzi gospodarki magazynowej oraz rozrachunków i rozliczeo finansowych,
jedynymi wystawianymi dokumentami są faktury.

Do realizacji naszego przykładu wykorzystane zostaną narzędzia: PowerDesigner 12.5, Sybase AS

Anywhere 9 wraz z serwerem synchronizacji MobiLink 9 (można wykorzystad oczywiście nowszą
wersje - bazę SQL Anywhere 10 wraz z MobiLink’iem 10).

2. Tworzenie modelu danych przy użyciu PowerDesigner

a. Model konceptualny danych

Modelowanie baz danych rozpoczynamy od utworzenia modelu konceptualnego. Zawierad on

będzie zbiór abstrakcyjnych pojęd, które umożliwią reprezentację określonych własności tego świata,
będących w obszarze naszych zainteresowao. Inaczej rzecz ujmując model konceptualny będzie
uproszczonym modelem fragmentu rzeczywistości bez konieczności wnikania w szczegóły
implementacyjne, które będą istotne w modelu fizycznym danych (Physical Data Model).

Pierwszym krokiem jest uruchomienie programu PowerDesigner i utworzenie nowego modelu

konceptualnego (Rys. 1)

Rysunek 1. Utworzenie nowego modelu konceptualnego

W pole Model name wpisujemy nazwę modelu. W tym przypadku niech będzie to Sklep.

Naciskamy OK. W obszarze roboczym (Workspace) pojawi nam się model z domyślnym diagramem.
Abyśmy uzyskali większą przejrzystośd zmienimy nazwę diagramu na Diagram główny. W tym celu
zaznaczamy myszką diagram i naciskamy F2, po czym zmieniamy nazwę (Rys.2).

Rysunek 2. Zmiana nazwy głównego diagramu modelu konceptualnego

Po prawej stronie okna mamy dostępną Paletę. W palecie do dyspozycji mamy wiele elementów,

które wykorzystad możemy do zbudowania modelu. Podstawowe z nich to:



pakiet

- logicznie spójny podmodel (zbiór podmodeli)



encja

- reprezentacja pojęcia (bytu lub abstrakcji)



związek między encjami

- związek pomiędzy pojęciami



dziedziczenie

- wyróżnione pojęcia mogą tworzyd hierarchię



asocjacja

- związek z atrybutami



związek asocjacyjny

- przynależnośd encji do asocjacji

Mając do dyspozycji wspomniane wyżej elementy zaczynamy budowad model. Rozpoczynamy od

zamodelowania encji i związków pomiędzy nimi, z uwzględnieniem zależności ze świata
rzeczywistego. Wybieramy z palety element Encji i stawiamy go na diagramie. Aby edytowad
właściwości tego elementu dwukrotnie klikamy na nim myszką (Rys.3). Zmieniamy nazwę encji na
Osoba, uzupełniamy komentarz, po czym przechodzimy na zakładkę Atrybuty.

Rysunek 3. Dodanie nowej encji do modelu konceptualnego

Na zakładce atrybuty naciskamy przycisk Add a Row (trzeci z lewej). Pojawi się nam się nowy atrybut
(Rys.4).

Rysunek 4. Dodanie atrybutu do encji

Aby przejśd do jego edycji naciskamy na przycisk Properties (pierwszy z lewej). Pojawi się

komunikat o konieczności zatwierdzenia zmian przed edycją obiektu, który potwierdzamy naciskając
przycisk Tak. Pojawi się okno właściwości atrybutu (Rys.5).

Rysunek 5. Wygląd okna właściwości atrybutu encji

Zmieniamy nazwę atrybutu na ID_KLIENTA, z listy typów danych wybieramy Integer oraz

zaznaczamy, że atrybut stanowi główny identyfikator encji (Rys.6) – zatwierdzamy naciskając klawisz
OK.

Rysunek 6. Ustawienie właściwości atrybutu ID_KLIENTA encji Osoba

W ten sam sposób dodajemy kolejne atrybuty (NAZWISKO, IMIE, PESEL, NIP). Pamiętad

należy, aby ustawid pole Mandatory tam, gdzie to potrzebne. Zaznaczenie tego pola oznacza, iż
wypełnienie tego atrybutu jest wymagane (Rys.7).

Rysunek 7. Encja Osoba z kompletem atrybutów

Przechodzimy na zakładkę Identyfikatory. Ze względu na to, iż przy tworzeniu atrybutu

ID_KLIENTA zaznaczyliśmy, że jest to identyfikator główny PowerDesigner automatycznie
wygenerował nam identyfikator. Zmieniamy jego nazwę na PI_Osoba. Proponuję dla przykładu dodad
jeszcze jeden identyfikator ręcznie. W tym celu naciskamy przycisk Add a Row i przechodzimy do
edycji nowoutworzonego rekordu. Nazwę zmieniamy na ID_Nip (Rys.8).

Rysunek 8. Dodanie nowego identyfikatora encji

Przechodzimy następnie do zakładki atrybuty. Naciskamy przycisk Add Attributes, po czym

wybieramy atrybuty (NIP), które mają należed do identyfikatora (Rys.9).

Rysunek 9. Okno dodawania pól do identyfikatora encji

Zatwierdzamy wszystkie okna przyciskami OK. Tworzymy dwie nowe encje Pracownik i Klient

uzupełniamy opisy tak, jak poprzednio. Klikamy na przycisk dziedziczenia i wskazując od encji
„dziecko” do encji „rodzic” ustalamy związek dziedziczenia (Rys.10).

Rysunek 10. Drzewo dziedziczenia w modelu konceptualnym

Następnie edytujemy związek dziedziczenia i przechodzimy do zakładki generacji. Zakładamy,

że encja Osoba jest encją abstrakcyjną, dlatego też na zakładce tej odznaczamy opcję Generate
parent (Rys.11) i zatwierdzamy.

Rysunek 11. Właściwości związku dziedziczenia

Aby nieco przyspieszyd wstawiamy encje Artykul, Faktura, Pozycja_faktury, dodajemy do nich

odpowiednie atrybuty (Rys.12). Klikamy na przycisk związku i wskazując od encji nadrzędnej (strona
jeden) do encji podrzędnej (strona wiele) ustalamy związki pomiędzy nimi.

Rodzaj osoby

Relationship_1

Relationship_2

Relationship_3

Relationship_4

Osoba

ID_KLIENTA
NAZWISKO
IMIE
PESEL
NIP

<pi>

<ai>

Integer
Variable characters (30)
Variable characters (30)
Variable characters (11)
Variable characters (13)

<M>
<M>
<M>

PI_Osoba
ID_Nip

<pi>
<ai>

Klient

Pracownik

Artykul

ID_ARTYKULU
NAZWA
CENA_NETTO
CENA_BRUTTO

<pi> Integer

Variable characters (20)
Decimal (10,2)
Decimal (10,2)

<M>
<M>
<M>
<M>

PI_Artykul <pi>

Faktura

ID_FAKTURY
NUMER
DATA_WYST
MIEJSCE_WYST

<pi> Integer

Variable characters (15)
Date
Variable characters (30)

<M>
<M>
<M>

PI_Faktura <pi>

Pozycja_faktury

LP
ILOSC
CENA_NETTO
CENA_BRUTTO

<pi> Integer

Decimal (10,4)
Decimal (10,2)
Decimal (10,2)

<M>
<M>
<M>
<M>

PI_PozycjaFaktury <pi>

Rysunek 12. Zamodelowanie związków pomiędzy encjami

Związki, które domyślnie tworzy PowerDesigner trzeba jeszcze doszlifowad. Edytujmy dla

przykładu związek pomiędzy Fakturą i Pozycją faktury. Zmieniamy nazwę związku (dla przykładu
stosujemy

konwencję

FK_%NAZWA_TAB_NADRZEDNEJ%_%NAZWA_TAB_PODRZEDNEJ%)

i

uzupełniamy komentarz (Rys.13).

Rysunek 13. Właściwości związku pomiędzy encjami

Przechodzimy na drugą zakładkę i uzupełniamy dane. W tym przypadku zależy nam na tym,

aby Pozycja faktury identyfikowana była również poprzez identyfikator Faktury. W związku z tym
zaznaczamy opcję Dependent przy encji Pozycja faktury (Rys.14).

Rysunek 14. Ustawienie liczności związku, jego typu oraz ról encji w związku

W podobny sposób poprawiamy kolejne związki pomiędzy encjami. W rezultacie uzyskujemy

model przedstawiony poniżej (Rys.15).

Rodzaj osoby

FK_Klinet_Faktura

Odbiorca

Dokumenty

FK_Pracownik_Faktura

Wystawca

Dokumenty

FK_Faktura_PozycjaFaktury

Dokument

Pozycje

FK_Artykul_PozycjaFaktury

Artykul

Pozycje

Osoba

ID_KLIENTA
NAZWISKO
IMIE
PESEL
NIP

<pi>

<ai>

Integer
Variable characters (30)
Variable characters (30)
Variable characters (11)
Variable characters (13)

<M>
<M>
<M>

PI_Osoba
ID_Nip

<pi>
<ai>

Klient

Pracownik

Artykul

ID_ARTYKULU
NAZWA
CENA_NETTO
CENA_BRUTTO

<pi> Integer

Variable characters (20)
Decimal (10,2)
Decimal (10,2)

<M>
<M>
<M>
<M>

PI_Artykul <pi>

Faktura

ID_FAKTURY
NUMER
DATA_WYST
MIEJSCE_WYST

<pi> Integer

Variable characters (15)
Date
Variable characters (30)

<M>
<M>
<M>

PI_Faktura <pi>

Pozycja_faktury

LP
ILOSC
CENA_NETTO
CENA_BRUTTO

<pi> Integer

Decimal (10,4)
Decimal (10,2)
Decimal (10,2)

<M>
<M>
<M>
<M>

PI_PozycjaFaktury <pi>

Rysunek 15. Gotowy model konceptualny

Istnieje również możliwośd wygenerowania modelu obiektowego (diagramu klas – Class

diagram) na podstawie przygotowanego modelu konceptualnego, który jest „logicznie” bliższy
diagramowi klas modelu obiektowego. Wygenerowad model obiektowy na podstawie modelu
konceptualnego danych można wybierając z menu opcję Tools->Generate Object-Oriented Model….
Pojawi się nam okno przedstawione na Rys. 15a na którym możemy określid język obiektowy np. Java
5.0. Wygenerowanie modelu obiektowego pozwoli nam na możliwośd zbudowania szkieletu aplikacji
w technologii obiektowej wykorzystując możliwośd operowania na relacyjnej bazie danych poprzez
mechanizm ORM (Object-Relation Mapping). Dla modelu obiektowego implementowanego w języku
Java może to byd przykładowo mechanizm ORM – Hibernate lub dla technologii .NET – NHibernate.

Rysunek 16. Generacja obiektowego modelu danych z modelu konceptualnego

Nazwę modelu obiektowego pozostawimy taką samą jak modelu konceptualnego, a język

obiektowy Object language ustawiamy na Java 5.0. Aby rozpocząd generację naciskamy przycisk OK.
Po generacji otrzymamy następujący widok (Rys.15b).

1..1

Odbiorca

0..*

Dokumenty

1..1

Wystawca

0..*

Dokumenty

1..1

Dokument

0..*

Pozycje

1..1

Artykul

0..*

Pozycje

Osoba

+
+
+
+
+

ID_KLIENTA
NAZWISKO
IMIE
PESEL
NIP

: int
: java.lang.String
: java.lang.String
: java.lang.String
: java.lang.String

Klient

Pracownik

Artykul

+
+
+
+

ID_ARTYKULU
NAZWA
CENA_NETTO
CENA_BRUTTO

: int
: java.lang.String
: double
: double

Faktura

+
+
+
+

ID_FAKTURY
NUMER
DATA_WYST
MIEJSCE_WYST

: int
: java.lang.String
: java.util.Date
: java.lang.String

Pozycja_faktury

+
+
+
+

LP
ILOSC
CENA_NETTO
CENA_BRUTTO

: int
: double
: double
: double

Rysunek 17. Wygenerowany model obiektowy – diagram klas

Tak przygotowany model obiektowy będzie stanowił punkt wyjścia do przygotowania

mechanizmu mapowania ORM. Opis realizacji mapowania ORM będzie przedmiotem następnego
opracowania.

b. Model fizyczny danych

Model fizyczny uzyskujemy generując go z modelu konceptualnego. Zaletą automatycznej

generacji modelu fizycznego jest to, iż PowerDesigner tworzy mapowanie pomiędzy modelami. W
rezultacie zmiany w którymkolwiek modelu możemy nanieśd szybko na drugi, oszczędziliśmy ponadto
czas na ręczne utworzenie modelu fizycznego od początku.

Generacje wywołujemy wybierając z menu opcję Tools->Generate Physical Data Model… lub

naciskając Ctrl+Shift+P. Pojawi nam się okno przedstawione na Rys.16.

Rysunek 18. Generacja fizycznego modelu danych z modelu konceptualnego

Wybieramy w pierwszej kolejności docelową bazę danych. W naszym przypadku będzie to

Sybase AS Anywhere 9. Nazwę modelu fizycznego pozostawimy taką samą jak modelu
konceptualnego. Aby rozpocząd generację naciskamy przycisk OK. Po generacji otrzymamy
następujący widok (Rys.17).

Rysunek 19. Wygenerowany model fizyczny

Widzimy, że generator trochę pozmieniał nam nazwy związków. Aby edytowad związek

klikamy na nim dwukrotnie (Rys.18).

Rysunek 20. Właściwości związku pomiędzy tabelami

Widzimy, iż wszystkie dane z modelu konceptualnego zostały przeniesione do modelu

fizycznego. Kopiujemy nazwę związku i przechodzimy na zakładkę Integrity (Integraność) (Rys.19).

Rysunek 21. Ustawienia reguł integralności związku

W pole Constraint Name wklejamy nazwę związku. Ponadto zaznaczamy opcję Cascade w

sekcji Delete Constraint (usuwając nagłówek faktury niech automatycznie usunie pozycje faktury).
Zatwierdzamy przez naciśnięcie OK. W podobny sposób edytujemy pozostałe związki. W rezultacie
otrzymamy model przedstawiony na Rys.20.

FK_Klinet_Faktura

Dokumenty

Odbiorca

FK_Pracownik_Faktura

Dokumenty

Wystawca

FK_Faktura_PozycjaFaktury

Pozycje

Dokument

FK_Artykul_PozycjaFaktury

Pozycje

Artykul

Klient

ID_KLIENTA
NAZWISKO
IMIE
PESEL
NIP

integer
varchar(30)
varchar(30)
varchar(11)
varchar(13)

<pk>

Pracownik

ID_KLIENTA
NAZWISKO
IMIE
PESEL
NIP

integer
varchar(30)
varchar(30)
varchar(11)
varchar(13)

<pk>

Artykul

ID_ARTYKULU
NAZWA
CENA_NETTO
CENA_BRUTTO

integer
varchar(20)
decimal(10,2)
decimal(10,2)

<pk>

Faktura

ID_FAKTURY
ID_KLIENTA
Pra_ID_KLIENTA
NUMER
DATA_WYST
MIEJSCE_WYST

integer
integer
integer
varchar(15)
date
varchar(30)

<pk>
<fk1>
<fk2>

Pozycja_faktury

ID_FAKTURY
LP
ID_ARTYKULU
ILOSC
CENA_NETTO
CENA_BRUTTO

integer
integer
integer
decimal(10,4)
decimal(10,2)
decimal(10,2)

<pk,fk1>
<pk>
<fk2>

Rysunek 22. Model fizyczny bazy danych po poprawieniu właściwości związków

Widzimy jednak, że w tabeli Faktura mamy dziwnie nazwaną kolumnę. Tabela ta ma dwie

tabele nadrzędne o takim samym kluczu głównym, dlatego też przy generacji PowerDesigner
zmodyfikował drugi z kluczy. Przechodzimy do edycji tabeli i w zakładce Columns edytujemy kolumnę
Pra_ID_KLIENTA. Zmieniamy jej nazwę na ID_PRACOWNIKA i zatwierdzamy (Rys.21).

FK_Klinet_Faktura

Dokumenty

Odbiorca

FK_Pracownik_Faktura

Dokumenty

Wystawca

FK_Faktura_PozycjaFaktury

Pozycje

Dokument

FK_Artykul_PozycjaFaktury

Pozycje

Artykul

Klient

ID_KLIENTA
NAZWISKO
IMIE
PESEL
NIP

integer
varchar(30)
varchar(30)
varchar(11)
varchar(13)

<pk>

Pracownik

ID_KLIENTA
NAZWISKO
IMIE
PESEL
NIP

integer
varchar(30)
varchar(30)
varchar(11)
varchar(13)

<pk>

Artykul

ID_ARTYKULU
NAZWA
CENA_NETTO
CENA_BRUTTO

integer
varchar(20)
decimal(10,2)
decimal(10,2)

<pk>

Faktura

ID_FAKTURY
ID_KLIENTA
ID_PRACOWNIKA
NUMER
DATA_WYST
MIEJSCE_WYST

integer
integer
integer
varchar(15)
date
varchar(30)

<pk>
<fk1>
<fk2>

Pozycja_faktury

ID_FAKTURY
LP
ID_ARTYKULU
ILOSC
CENA_NETTO
CENA_BRUTTO

integer
integer
integer
decimal(10,4)
decimal(10,2)
decimal(10,2)

<pk,fk1>
<pk>
<fk2>

Rysunek 23. Model fizyczny bazy danych po poprawieniu nazw wygenerowanych kolumn

Aby widzied po jakich polach łączone są tabele zmienimy jeszcze opcje wyświetlania.

Wchodzimy do Tools->Display Preferences…, na drzewku w sekcji Object View wybieramy Reference.
Zaznaczamy Join i Referential integrity (Rys.22).

Rysunek 24. Zmiana preferencji wyświetlania związków na modelu

Następnie wybieramy w tej samej sekcji Table i zaznaczamy NULL/NOT NULL (Rys.23) po

czym zatwierdzamy przyciskiem OK.

Rysunek 25. Zmiana preferencji wyświetlania tabel na modelu

W rezultacie uzyskujemy przejrzysty model fizyczny danych (Rys.24).

ID_KLIENTA = ID_KLIENTA

Upd(R); Del(R);cpa

Dokumenty

Odbiorca

ID_KLIENTA = ID_PRACOWNIKA

Upd(R); Del(R);cpa

Dokumenty

Wystawca

ID_FAKTURY = ID_FAKTURY

Upd(R); Del(C);cpa

Pozycje

Dokument

ID_ARTYKULU = ID_ARTYKULU

Upd(R); Del(R);cpa

Pozycje

Artykul

Klient

ID_KLIENTA
NAZWISKO
IMIE
PESEL
NIP

integer
varchar(30)
varchar(30)
varchar(11)
varchar(13)

<pk> not null

not null
not null
null
null

Pracownik

ID_KLIENTA
NAZWISKO
IMIE
PESEL
NIP

integer
varchar(30)
varchar(30)
varchar(11)
varchar(13)

<pk> not null

not null
not null
null
null

Artykul

ID_ARTYKULU
NAZWA
CENA_NETTO
CENA_BRUTTO

integer
varchar(20)
decimal(10,2)
decimal(10,2)

<pk> not null

not null
not null
not null

Faktura

ID_FAKTURY
ID_KLIENTA
ID_PRACOWNIKA
NUMER
DATA_WYST
MIEJSCE_WYST

integer
integer
integer
varchar(15)
date
varchar(30)

<pk>
<fk1>
<fk2>

not null
not null
not null
not null
not null
null

Pozycja_faktury

ID_FAKTURY
LP
ID_ARTYKULU
ILOSC
CENA_NETTO
CENA_BRUTTO

integer
integer
integer
decimal(10,4)
decimal(10,2)
decimal(10,2)

<pk,fk1>
<pk>
<fk2>

not null
not null
not null
not null
not null
not null

Rysunek 26. Model fizyczny bazy danych w widoku zgodnym z preferencjami wyświetlania

Ograniczyliśmy się tu tylko do „doszlifowania” modelu wygenerowanego przez PowerDesigner.

W palecie do dyspozycji mamy wiele elementów, które wykorzystad możemy do
zbudowania/rozbudowania modelu. Podstawowe z nich to:



pakiet

- logicznie spójny podmodel (zbiór podmodeli)



tabela

- relacja (reprezentacja encji)



widok

- w wielkim skrócie jest to nazwane zapytanie



związek

- związek pomiędzy tabelami



procedury składowane

- bloki kodu

3. Model rozproszonej bazy danych

Do tej pory budowany był model centralnej bazy danych, który jednocześnie w naszym przypadku

będzie również modelem bazy danych oddziałów firmy. Głównym celem naszego zadania w tym
punkcie jest zbudowanie modelu rozproszonej bazy danych wraz z określeniem mechanizmu
replikacji – synchronizacji danych pomiędzy bazami danych. W naszym przypadku wykorzystamy do
budowy systemu rozproszonych baz danych model gwiazdy, czyli w „punkcie centralnym” znajduje
się centralna baza danych a na obrzeżach bazy danych oddziałów. Replikacja określona będzie tylko
pomiędzy bazą centralną a bazami oddziałów. W naszym przykładzie pokażemy, w jaki sposób
zamodelowad, zdefiniowad i zrealizowad mechanizm replikacji pomiędzy bazą centralną a bazą
danych jednego oddziału. W sposób analogiczny należałoby wykonad mechanizm synchronizacji
pomiędzy bazą centralną a pozostałymi bazami danych oddziałów.

W pierwszym kroku dodajemy nowy model do przestrzeni roboczej (Workspace). Wybieramy

File->New i z listy dostępnych modelów wybieramy Information Liquidity Model (Rys. 25) i zmieniamy
nazwę modelu na Sklep.

Rysunek 27 Dodanie modelu rozproszenia

Przechodzimy na zakładkę Rozszerzonych definicji modelu (Extended Model Definitions) i

zaznaczamy na liście MobiLink 9.0. Jest to serwer synchronizacji, który będziemy wykorzystywad w
naszym rozwiązaniu (Rys.26).

Rysunek 28 Dobranie rozszerzonych definicji modelu

Po zatwierdzeniu przyciskiem OK., model zostaje dodany do przestrzeni roboczej. Od razu

możemy zmienid nazwę diagramu na Diagram główny (Rys.27).

Rysunek 29 Widok workspace i palety po dodaniu modelu rozproszonego

Jak i w poprzednich rodzajach modeli, tak i tutaj dostępną mamy paletę (Rys.27). W palecie do

dyspozycji mamy wiele elementów, które wykorzystad możemy do zbudowania modelu. Podstawowe
z nich to:



pakiet

- logicznie spójny podmodel (zbiór podmodeli)



serwer

- host, na którym postawiona jest baza danych



baza danych

- składnica danych, której schemat oparty jest na wybranym modelu

fizycznym



MobiLink

- reprezentuje serwer synchronizacji MobiLink



Łącze dostępu do danych

- związek, który określa sposób mapowania danych pomiędzy

składnicami danych

Zaleca się, aby serwer synchronizacji był uruchomiony na innej maszynie niż serwer bazy danych.

W związku z tym wstawiamy trzy serwery – odpowiednio dla bazy centralnej, zdalnej i serwera
synchronizacji (Rys.28).

Centrala

Synchronizacja

Oddzial

Rysunek 30 Dostępne węzły

Następnie dla serwerów Centrala i Oddziału dodajemy komponent bazy danych (Rys.29).

Centrala

Centrala.Sklep

Synchronizacja

Oddzial

Oddzial.Sklep

Rysunek 31 Bazy danych na węzłach

Wstawiając komponent na serwer nie określiliśmy, jaką strukturę będzie miała ta baza. W

związku z tym wyświetlamy właściwości bazy centralnej i uzupełniamy dane (Rys.30).

Rysunek 32 Właściwości bazy danych na węźle centralnym

Następnie przechodzimy na zakładkę Fizyczne modele danych (Physical Data Models), po

czym naciskamy przycisk Dodaj istniejące fizyczne modele danych (drugi przycisk z lewej). Z listy
modeli wybieramy model utworzony przez nas wcześniej (Rys.31). Uwaga, na liście dostępne są tylko
te modele, które znajdują się w przestrzeni roboczej oraz zostały otworzone.

Rysunek 33 Przypisanie modelu do bazy danych

Do węzła Synchronizacja dodajemy komponent serwera synchronizacji MobiLink (Rys.32).

Centrala

Centrala.Sklep

Synchronizacja

Replikator

(MobiLink 9.0)

Oddzial

Oddzial.Sklep

Rysunek 34 Serwer synchronizacji

W tej chwili mamy już wszystkie komponenty, które są nam potrzebne. Aby jednak wszystko

działało tak jak potrzeba, czyli dane replikowały się z serwera centralnego do zdalnego, a zmiany
wracały z powrotem musimy skonfigurowad replikację danych. PowerDesigner pozostawia nam
bardzo duże pole do działania w tym zakresie. Jeżeli ktoś nie ma jednak czasu, wiedzy lub nie jest mu
potrzebna bardziej złożona logika, może użyd dostępnego kreatora replikacji. Aby pokazad ideę opcja
ta nam w zupełności wystarczy. Wybieramy z menu Tools->Replication Wizard… (Rys.33).

Rysunek 35 Uruchomienie kreatora replikacji

W pierwszym kroku kreatora wybieramy połączenie ze źródłową (centralną) bazą danych. Ze

względu na to, iż nie mamy jeszcze skonfigurowanych żadnych połączeo wybierzemy bazę ze
słownika dostępnych obiektów. Naciskamy na przycisk znajdujący się po prawej stronie listy i ze
słownika wybieramy bazę Centrala.Sklep (Rys.34).

Rysunek 36 Ustawienie bazy źródłowej dla replikacji

Kolejny krok kreatora to wybór procesu (komponentu) replikującego dane (Rys.35). Na liście

nie mamy jednak dostępnej żadnej opcji, klikamy więc na przycisk po jej prawej stronie.

Rysunek 37 Ustawienie procesu replikującego oraz jego typu

Po naciśnięciu przycisku pojawi nam się okno z listą dostępnych komponentów synchronizacji

(Rys.36). Wybieramy komponent Replikator i zatwierdzamy naciskając przycisk OK.

Rysunek 38 Wybór procesu replikującego z dostępnych w modelu

W następnym kroku określamy publikacje, czyli pewne zbiory tabel do synchronizacji

(Rys.37). Załóżmy, że chcemy synchronizowad wszystko naraz. W związku z tym wybieramy pierwszą
opcję i wpisujemy nazwę publikacji, np. PublishAll.

Rysunek 39 Utworzenie publikacji

Teraz do podanej przed chwilą publikacji dodajemy tabele (Rys.38). Zgodnie z założeniem

wybieramy wszystko.

Rysunek 40 Wybór tabel do publikacji

W tym kroku kreatora replikacji wybieramy z listy połączenie do zdalnej bazy danych (Rys.39).

Ze względu na to, że nie mamy utworzonych jeszcze żadnych połączeo, musimy najpierw wskazad
obiekt docelowy. Naciskamy na przycisk po prawej stronie pola tekstowego.

Rysunek 41 Określenie bazy zdalnej

Wyświetlona została lista dostępnych baz danych (Rys.40). Z listy tej wybieramy bazę zdalną

Oddzial.Sklep i zatwierdzamy.

Rysunek 42 Wybór bazy zdalnej z dostępnych w modelu

W związku z tym, że baza docelowa nie ma jeszcze określonego żadnego modelu fizycznego

musimy go teraz określid. Ze względu na to, iż częśd zdalna może byd tylko podzbiorem tabel
dostępnych w modelu bazy centralnej, dobrym nawykiem jest utworzenie nowego modelu dla bazy
zdalnej (Rys.41).

Rysunek 43 Wybór modelu bazy zdalnej

Ostatnim krokiem kreatora jest naniesienie zmian na model bazy zdalnej (Rys.42). W naszym
przypadku model ten zostanie dopiero utworzony. Aby zakooczyd kreatora i wykonad tę operację
naciskamy przycisk Zakoocz.

Rysunek 44 Zakooczenie kreatora replikacji

W wyniku działania kreatora otrzymujemy model zdalnej bazy danych widoczny na Rys.43

oraz model rozproszony ze skonfigurowaną replikacją widoczny na Rys.44.

Rysunek 45 Model bazy zdalnej wygenerowany przez kreator replikacji

Centrala

Centrala.Sklep

Synchronizacja

Replikator

(MobiLink 9.0)

Oddzial

Oddzial.Sklep

Rysunek 46 Model rozproszony z ustawioną replikacją

Aby wszystko działało jak należy potrzebne jest jeszcze skonfigurowanie samego serwera

replikacji. Klikamy na komponent serwera i z menu kontekstowego wybieramy Właściwości.
Przechodzimy następnie na zakładkę Opcji MobiLink i ustawiamy nasze preferencje odnośnie
sposobów zarządzania danymi w bazie centralnej oraz ich pobierania do bazy zdalnej (Rys.45). Aby
uzyskad efekt synchronizacji przyrostowej użyjemy kolumny ze znacznikiem czasowym daty ostatniej
modyfikacji rekordu, ponadto użyjemy tabeli pomocniczej (Shadow table) do zarządzania rekordami
usuniętymi, wersję skryptów pozostawimy jako default.

Rysunek 47 Parametry serwera synchronizacji

Ze względu na to, iż baza zdalna musi połączyd się z serwerem synchronizacji aby pobrad

dane z bazy centralnej należy jeszcze skonfigurowad to połączenie. Wybieramy właściwości zdalnej
bazy danych i przechodzimy na zakładkę MobiLink. Konfigurujemy częśd dotyczącą połączenia.
Ustawiamy typ synchronizacji na TCP/IP, wpisujemy nazwę hosta z serwerem synchronizacji (tu
localhost) oraz numer portu, na którym działa (standardowy port zarezerwowany dla serwera
MobiLink to 2439).

Rysunek 48 Parametry synchronizacji dla bazy zdalnej

Przechodzimy następnie do zakładki użytkowników (Rys.47). Tutaj ustawiamy listę

użytkowników synchronizacji. Niech będzie dla przykładu jeden użytkownik MLUser i hasłem 123.

Rysunek 49 Użytkownicy synchronizacji bazy zdalnej

Wydaje się, że zrobiliśmy już wszystko co powinniśmy, aby wszystko działało jak należy.

Prawie jest to prawda. Jak pamiętamy ustawialiśmy wcześniej parametry serwera synchronizacji,
gdzie określaliśmy sposób pobierania danych, zarządzania rekordami usuniętymi, itp. Ustawiliśmy
tam między innymi kolumnę ze znacznikiem czasowym, ale jak możemy zauważyd kolumny tej nie
mamy przecież w modelu bazy centralnej tak jak i tabel pomocniczych do zarządzania rekordami
usuniętymi. Należałoby dodad te elementy teraz, aby dopełnid już wszystkich formalności.
Dodawanie każdego elementu ręcznie, szczególnie przy dużym modelu byłoby bardzo czasochłonne.
Na szczęście mamy mechanizm, który zrobi to za nas. Klikamy na bazę centralną prawym przyciskiem
myszy i z menu kontekstowego i wybieramy Update consolidated database PDM. Pojawi nam się
komunikat, że fizyczny model danych zostanie uzupełniony o brakujące tabele, kolumny, procedury
składowane i triggery. Potwierdzamy. W rezultacie uzyskaliśmy model fizyczny centralnej bazy
danych widoczny na Rys.48. Jak widzimy utworzone zostały tabele pomocnicze, dodana została
kolumna last_modified oraz do każdej tabeli dodano po trzy triggery.

ID_KLIENTA = ID_KLIENTA

Upd(R); Del(R);cpa

Dokumenty

Odbiorca

ID_KLIENTA = ID_PRACOWNIKA

Upd(R); Del(R);cpa

Dokumenty

Wystawca

ID_FAKTURY = ID_FAKTURY

Upd(R); Del(C);cpa

Pozycje

Dokument

ID_ARTYKULU = ID_ARTYKULU

Upd(R); Del(R);cpa

Pozycje

Artykul

Klient

ID_KLIENTA
NAZWISKO
IMIE
PESEL
NIP
last_modified

integer
varchar(30)
varchar(30)
varchar(11)
varchar(13)
timestamp

<pk> not null

not null
not null
null
null
null

pdml_ti_Klient
pdml_tu_Klient
pdml_td_Klient

Pracownik

ID_KLIENTA
NAZWISKO
IMIE
PESEL
NIP
last_modified

integer
varchar(30)
varchar(30)
varchar(11)
varchar(13)
timestamp

<pk> not null

not null
not null
null
null
null

pdml_ti_Pracownik
pdml_tu_Pracownik
pdml_td_Pracownik

Artykul

ID_ARTYKULU
NAZWA
CENA_NETTO
CENA_BRUTTO
last_modified

integer
varchar(20)
decimal(10,2)
decimal(10,2)
timestamp

<pk> not null

not null
not null
not null
null

pdml_ti_Artykul
pdml_tu_Artykul
pdml_td_Artykul

Faktura

ID_FAKTURY
ID_KLIENTA
ID_PRACOWNIKA
NUMER
DATA_WYST
MIEJSCE_WYST
last_modified

integer
integer
integer
varchar(15)
date
varchar(30)
timestamp

<pk>
<fk1>
<fk2>

not null
not null
not null
not null
not null
null
null

pdml_ti_Faktura
pdml_tu_Faktura
pdml_td_Faktura

Pozycja_faktury

ID_FAKTURY
LP
ID_ARTYKULU
ILOSC
CENA_NETTO
CENA_BRUTTO
last_modified

integer
integer
integer
decimal(10,4)
decimal(10,2)
decimal(10,2)
timestamp

<pk,fk1>
<pk>
<fk2>

not null
not null
not null
not null
not null
not null
null

pdml_ti_Pozycja_faktury
pdml_tu_Pozycja_faktury
pdml_td_Pozycja_faktury

Klient_deleted

ID_KLIENTA
delete_time

integer
timestamp

<pk> not null

null

Pracownik_deleted

ID_KLIENTA
delete_time

integer
timestamp

<pk> not null

null

Artykul_deleted

ID_ARTYKULU
delete_time

integer
timestamp

<pk> not null

null

Faktura_deleted

ID_FAKTURY
delete_time

integer
timestamp

<pk> not null

null

Pozycja_faktury_deleted

ID_FAKTURY
LP
delete_time

integer
integer
timestamp

<pk>
<pk>

not null
not null
null

Rysunek 50 Zaktualizowany model bazy centralnej

W tym miejscu pozostało nam tylko wygenerowanie wszystkich potrzebnych skryptów. Aby

wygenerowad skrypty zakładające bazy danych naciskamy na komponencie bazy danych prawym
przyciskiem myszy i z menu kontekstowego wybieramy Generate database. Potrzebne są nam
również skrypty konfigurujące replikację, zarówno dla bazy centralnej jak i dla replikatora (MobiLink).
Postępujemy identycznie jak przed chwilą z tym, że teraz wybieramy Generate scripts.

Podsumowując całe powyższe zadanie możemy powiedzied, iż PowerDesigner spełnia

pokładane w nim nadzieje. Udało nam się szybko utworzyd model rozproszony. Narzędzie to
umożliwiło nam kompleksowe podejście do problemu – kilka modeli pokazujących z różnych stron
różne aspekty zadania.

Spis rysunków

Rysunek 1. Utworzenie nowego modelu konceptualnego ...................................................................... 3
Rysunek 2. Zmiana nazwy głównego diagramu modelu konceptualnego .............................................. 3
Rysunek 3. Dodanie nowej encji do modelu konceptualnego ................................................................ 4
Rysunek 4. Dodanie atrybutu do encji .................................................................................................... 5
Rysunek 5. Wygląd okna właściwości atrybutu encji .............................................................................. 5
Rysunek 6. Ustawienie właściwości atrybutu ID_KLIENTA encji Osoba .................................................. 6
Rysunek 7. Encja Osoba z kompletem atrybutów ................................................................................... 7
Rysunek 8. Dodanie nowego identyfikatora encji ................................................................................... 8
Rysunek 9. Okno dodawania pól do identyfikatora encji ........................................................................ 9
Rysunek 10. Drzewo dziedziczenia w modelu konceptualnym ............................................................... 9
Rysunek 11. Właściwości związku dziedziczenia ................................................................................... 10

Rysunek 12. Zamodelowanie związków pomiędzy encjami .................................................................. 11
Rysunek 13. Właściwości związku pomiędzy encjami ........................................................................... 12
Rysunek 14. Ustawienie liczności związku, jego typu oraz ról encji w związku .................................... 13
Rysunek 15. Gotowy model konceptualny ............................................................................................ 14
Rysunek 15a. Generacja obiektowego modelu danych z modelu konceptualnego .............................. 15
Rysunek 15b. Wygenerowany model obiektowy – diagram klas .......................................................... 16
Rysunek 16. Generacja fizycznego modelu danych z modelu konceptualnego .................................... 17
Rysunek 17. Wygenerowany model fizyczny ........................................................................................ 18
Rysunek 18. Właściwości związku pomiędzy tabelami ......................................................................... 19
Rysunek 19. Ustawienia reguł integralności związku ............................................................................ 20
Rysunek 20. Model fizyczny bazy danych po poprawieniu właściwości związków ............................... 21
Rysunek 21. Model fizyczny bazy danych po poprawieniu nazw wygenerowanych kolumn ............... 21
Rysunek 22. Zmiana preferencji wyświetlania związków na modelu ................................................... 22
Rysunek 23. Zmiana preferencji wyświetlania tabel na modelu ........................................................... 23
Rysunek 24. Model fizyczny bazy danych w widoku zgodnym z preferencjami wyświetlania ............. 23
Rysunek 25 Dodanie modelu rozproszenia ........................................................................................... 25
Rysunek 26 Dobranie rozszerzonych definicji modelu .......................................................................... 25
Rysunek 27 Widok workspace i palety po dodaniu modelu rozproszonego ......................................... 26
Rysunek 28 Dostępne węzły .................................................................................................................. 27
Rysunek 29 Bazy danych na węzłach ..................................................................................................... 27
Rysunek 30 Właściwości bazy danych na węźle centralnym................................................................. 28
Rysunek 31 Przypisanie modelu do bazy danych .................................................................................. 29
Rysunek 32 Serwer synchronizacji ........................................................................................................ 29
Rysunek 33 Uruchomienie kreatora replikacji ...................................................................................... 30
Rysunek 34 Ustawienie bazy źródłowej dla replikacji ........................................................................... 31
Rysunek 35 Ustawienie procesu replikującego oraz jego typu ............................................................. 31
Rysunek 36 Wybór procesu replikującego z dostępnych w modelu ..................................................... 32
Rysunek 37 Utworzenie publikacji ........................................................................................................ 33
Rysunek 38 Wybór tabel do publikacji .................................................................................................. 33
Rysunek 39 Określenie bazy zdalnej ...................................................................................................... 34
Rysunek 40 Wybór bazy zdalnej z dostępnych w modelu ..................................................................... 35
Rysunek 41 Wybór modelu bazy zdalnej ............................................................................................... 36
Rysunek 42 Zakooczenie kreatora replikacji ......................................................................................... 36
Rysunek 43 Model bazy zdalnej wygenerowany przez kreator replikacji ............................................. 37
Rysunek 44 Model rozproszony z ustawioną replikacją ........................................................................ 38
Rysunek 45 Parametry serwera synchronizacji ..................................................................................... 39
Rysunek 46 Parametry synchronizacji dla bazy zdalnej ........................................................................ 40
Rysunek 47 Użytkownicy synchronizacji bazy zdalnej ........................................................................... 41
Rysunek 48 Zaktualizowany model bazy centralnej .............................................................................. 42