pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
Rozdział 14
w
Modyfikacje schematu ERD na potrzeby
automatycznej wizualizacji obiektów GUI
w
1 Wstęp
da
.b
w
Streszczenie. W rozdziale zaproponowano modyfikacje schematu ERD
poprzez dodanie metadanych określających kategorie dla obiektów. Podejście
to umożliwia automatyczną wizualizację obiektów GUI. Przy nieznacznie
wydłużonym czasie projektowania uzyskujemy możliwość generacji ponad
80% stron lub formatek dla użytkownika końcowego. W przypadku zmian
dokonywanych w schemacie, automatyczna generacja pozwala na szybkie
przeniesienie tych zmian na strony oraz formatki.
2 Prace pokrewne
pl
s.
Procesy projektowania i implementacji w przypadku większości aplikacji przebiegają
podobnie. Kolejno projektowany jest schemat konceptualny, z którego tworzony jest
schemat logiczny [1]. Większość programów umożliwia wygenerowanie schematu
fizycznego, a następnie skryptu tworzącego bazę danych. Najbardziej pracochłonną częścią
jest implementacja GUI (ang. Graphical User Interface), czyli graficznego interfejsu
użytkownika (formatki, strony HTML lub PHP/ASP/JSP). Istnieją pewne aplikacje, które
pozwalają na generowanie pojedynczych obiektów GUI tj.: kontrolek (elementów
wizualnych) a nawet całych formatek lub stron internetowych [2] [3]. Niestety, problemem
są złożone i czasochłonne operacje złączenia bardzo wielu tabel w aplikacjach
bazodanowych. Po dokładnej analizie procesu projektowania formatek, można zauważyć,
że większość elementów powtarza się i można podzielić je na pewne kategorie. Z takich
wniosków zrodziła się idea zmian schematów danych już na poziomie projektowania, aby
koszty implementacji GUI były jak najniższe. Odbiorcą takiego systemu są projektanci
systemów bazodanowych, gdzie można wyróżnić poszczególne kategorie obiektów na
schemacie ERD.
Modyfikacja schematu ERD poprzez dodanie metadanych była już rozpatrywana w wielu
aplikacjach do projektowania, natomiast autorzy skupiali się głównie na opisie
i generowaniu dokumentacji, nie na wspomaganiu tworzenia (generowania) części GUI.
Sławomir Bańkowski, Michał Gorawski
Politechnika Śląska, Instytut Informatyki, ul. Akademicka 16, 44-100 Gliwice, Polska
email:{slawomir.bankowski,michal.gorawski}@polsl.pl
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
S. Bankowski, M. Gorawski
w
Dla wielu aplikacji warstwa pośrednia, czyli obiekty biznesowe (lub klasy trwałe), jest
zastąpiona poprzez odpowiednie procedury lub funkcje dla konkretnej instancji bazy
danych. Niektóre aplikacje (Tomahawk, JDeveloper, JBuilder) skupiają się na
pojedynczych obiektach (zazwyczaj encjach), które można łatwo przenieść na postać
formatki lub strony (HTML, ASP lub JSP) [4] [5]. Takie rozwiązanie jest dobre, jednak
przy dużej liczbie tabel, czas projektowania lub dokonywania zmian jest ciągle bardzo
duży. Dodatkowo, istnieje prawdopodobieństwo, że projektant lub programista przeoczy
pewne ważne połączenia, które mogą być niezbędne użytkownikowi końcowemu (klienta
systemu). Wynika to z faktu, że projektanci nie zawsze spełniają wszystkie potrzeby
użytkownika końcowego. W fazie użytkowania bardzo często okazuje się, że aplikacja nie
zawiera sporej części koniecznych elementów, które nie zostały zdefiniowane w pierwszym
projekcie systemu. Możliwość pokazania użytkownikowi części działania aplikacji już
w fazie projektowania pomaga uniknąć wielu nieporozumień.
Istnieją pewne szablony (np.: w Rational Rose), które umożliwiają wygenerowanie
części kodu odpowiadającego za silnik aplikacji, czyli wygenerowanie kodu dla znacznej
części klas trwałych. Jest to znaczne ułatwienie, jednak spotykamy się z sytuacją, kiedy do
bardzo dużej ilości wygenerowanego kodu trzeba dopisać silnik, bardzo często powtarzając
te same czynności wiele razy.
w
w
da
.b
3 Rozpatrywany schemat
Rozpatrywany jest schemat będący częścią schematu dla systemu LMS (Learning
Management System) do zarządzania zajęciami (wirtualne teczki), zaprojektowanego na
Politechnice Śląskiej. Wycinek zawiera 14 z 70 tabel. Strzałki oznaczają kierunek kluczy
obcych (grot strzałki pokazuje w której tabeli jest klucz główny).
przedmiot
prowadzacy
pracownik
przedmiot_instancja
grupa_typ
grupa_studenci
zajecie
dzien_tygodnia
obecnosc
pl
s.
grupa
uzytkownik
ocena
student
obecność_typ
Rys. 1. Wycinek rozpatrywanego schematu ERD
Bez trudu można określić i nazwać pewne zależności, które są słownikowe (typowe nie
tylko dla jednego przypadku). Przykładowo, encja dzien_tygodnia jest typu słownikowego,
podobnie jak encje grupa_typ i obecność_typ. Encja przedmiot_instancja jest naturalnym
rodzicem (lub agregatem) encji grupa, ponieważ dla jednej instancji przedmiotu można
wskazać kilka grup należących do tej instancji. Podobnie, encja przedmiot jest rodzicem dla
przedmiot_instancja.
166
Modyfikacje schematu ERD na potrzeby automatycznej wizualizacji obiektów GUI
4 Modyfikacje ERD
w
Schemat ERD zawiera trzy podstawowe elementy: encję, relację, atrybut. Aktualnie nie
skupiamy się na "słabej encji", "słabej relacji", a także atrybutach kluczowych i atrybutach
wielowartościowych, ponieważ nie ma to znaczenia na tym etapie modelowania.
Opracowane zostały kategorie dla obiektów schematu ERD:
1) Kategorie dla encji:
a) Dictionary (small, medium, big) - tabela słownikowa.
b) Partial - tabela częściowa, całość informacji jest tworzona poprzez złączenie
kilku innych tabel (przykładem takiej tabeli jest ocena), zawarte są informacje
na przecięciu pewnych innych tabel (ocena wystawiona przez prowadzącego dla
studenta w ramach pewnej grupy). Encja Partial powinna być połączona za
pomocą dwóch lub więcej relacji typu Fact, może posiadać inne, dodatkowe
relacje opisujące.
c) Information (reference, parent, main) - tabela informacyjna, najbardziej
popularna kategoria.
d) Actions (saferead, readonly, writeonly, rwonly, editable) - akcje właściwe dla
encji: zapis, odczyt, edycja. Nie jest to związane z prawami dostępu do
określonych akcji dla encji, jest to zbiór wszystkich odpowiednich logicznie
akcji, które można określić dla encji.
e) Aggregable (countable, sumable, minable, maxable) - agregacje, jakie można
wykonywać na atrybutach encji.
f) User (owner, partial, child) - czy jest to tabela zawierająca informacje
o użytkownikach w formie pośredniej (student, pracownik) lub bezpośredniej
(użytkownik).
2) Kategorie dla relacji:
a) Parent - określenie rodzicielstwa dla relacji, jedna encja jest rodzicem, druga
jest dzieckiem, wyznaczane jest to zawsze za pomocą krotności relacji.
b) Owner - właściciel informacji, relacja powinna być powiązana pomiędzy encją
o kategorii Dictionary, Information lub Partial, a User.
c) Dictionary - zależność słownikowa.
d) Information - zależność informacyjna, przykładem takiej zależności jest dzień
tygodnia dla zajęć.
e) Fact - łączy tabele wskazując na informacje połączone ze sobą w tabelach
Partial. Przykładem takiej zależności jest student i użytkownik.
3) Kategorie dla atrybutów:
a) Primary key
b) Foreign key
c) Name (simple, partial, complex)
d) Information
e) Category
f) Comment
g) Aggregable (countable, sumable, minable, maxable)
Dla każdego elementu można przypisać kategorię, która determinuje użycie tego elementu
w dalszej fazie projektowania. Nazwy w nawiasie są typami kategorii. O ile każdemu
elementowi można przypisać kilka kategorii, to w ramach określonej kategorii można
wybrać tylko jeden typ. Niektóre kategorie mogą się wykluczać, dlatego została utworzona
mapa kategorii, która wskazuje czy dwie kategorie mogą wystąpić dla jednego elementu.
da
.b
w
w
pl
s.
167
w
Dla encji mapa wygląda następująco (dla relacji i atrybutów większość kategorii się
wyklucza i nie jest zalecane ustawianie więcej niż dwie kategorie dla jednego obiektu):
Dictionary Partial Information Actions Aggregable
Dictionary
?
Partial
OK.
Information X
OK.
OK.
OK.
Actions
OK.
OK
OK.
Aggregable ?
X
OK
X
OK
OK
User
OK. – można użyć dwóch kategorii w ramach obiektu,
X – nie można użyć dwóch kategorii w ramach obiektu,
? – nie jest zalecane użycie wybranych dwóch kategorii w ramach obiektu.
w
5 Przykłady modyfikacji
w
da
.b
W przypadku, gdy encja posiada kategorie Dictionary(small) Actions(rwonly), oznacza to,
że jest to tabela słownikowa i właściwymi operacjami są: lista, dodanie elementu. Aby
utworzyć formatkę dodawania, należy przede wszystkim skupić się na atrybutach
o kategorii Name i Category. Jeżeli dodany jest element innej encji, która jest powiązana
relacją Dictionary z tabelą Dictionary(small), to zostanie wyświetlony ComboBox
w którym znajdą się wartości atrybutu o kategorii Name.
grupa
dzien_tygodnia
Dictionary(small)
dzien_tygodnia_nazwa
Name
Rys. 2. Modelowanie kategorii dla encji na schemacie logicznym
pl
s.
Dla powyższego schematu (rys.2.) przy dodawaniu grupy należy na ostatniej stronie
zamieścić ComboBox (lista rozwijana), w którym znajdą się wartości z kolumny
dzien_tygodnia_nazwa dla tabeli dzien_tygodnia.
Każdy atrybut posiada kategorię, która jest związana z faktem wyświetlania tak/nie, ale
także z kolejnością wyświetlania na stronie (lub formatce). Poniżej (rys.3.) przedstawiona
jest encja grupa, która posiada 5 atrybutów, a także 4 relacje. Aby wyświetlić listę grup
jako tabelę, nie wystarczą tylko kolumny utworzone z atrybutów. Do tabeli grup należy
przede wszystkim dodać informacje z tej encji, która pozostaje w relacji o atrybucie Parent
(czyli encja przedmiot_instancja).
Tabela powinna zawierać:
1) atrybuty o kategorii Name dla encji jako Parent (także na wyższych poziomach) nazwa przedmiotu, nazwa instancji przedmiotu,
2) atrybuty o kategorii Name dla danej encji - nazwa grupy, numer grupy,
3) atrybuty o kategorii Name dla wszystkich encji o kategorii Dictionary połączonej
z daną encją relacją o kategorii Dictionary - typ grupy, dzień tygodnia,
4) atrybuty o kategorii Information dla encji - co ile tygodni, czas trwania, godzina
początkowa,
168
5) atrybuty o kategorii Comment dla encji.
grupa_nazwa
Name
grupa_numer
co_ile_tygodni
czas_trwania
w
grupa
Information
godzina_pocz
przedmiot_instancja
Parent
w
pracownik
Owner
grupa_typ
Dictionary
dzien_tygodnia
w
Rys. 3. Kategorie dla atrybutów i relacji na schemacie logicznym
przedmiot
da
.b
Kolejnym przykładem typowego połączenia jest rodzic-dziecko (kategoria Parent). Dla
relacji o takiej kategorii wiemy, że przy dodawaniu nowego elementu dla określonej encji,
musimy szukać encji, która jest "rodzicem". Zdefiniowane nowego elementu zawsze
powinno się zaczynać na podstawie wyznaczenia rodzica.
grupa_nazwa
Name
grupa_numer
1
grupa
co_ile_tygodni
N
przedmiot_instancja
1
czas_trwania
Parent
B)
pl
s.
N
grupa
grupa
A)
Information
godzina_pocz
dzien_tygodnia
C)
grupa_typ
Dictionary
Rys. 4. Trzy podstawowe typy połączenia encji z innymi encjami i atrybutami
Dla przykładu na powyższym schemacie (rys.4.), dodanie grupy powinno się odbywać na
podstawie wybrania przedmiotu (pierwsza strona – rys.4A.), a następnie instancji
przedmiotu (druga strona – rys.4B.). Na trzeciej stronie powinny się znaleźć atrybuty dla
encji grupa i dla innych encji powiązanych relacjami o kategoriach: Information,
Dictionary (rys.4C.).
169
6 Generowanie wizualizacji na podstawie zmodyfikowanego
schematu ERD
Poniżej przedstawiony jest wycinek schematu ERD (rys.5.), dla którego zostanie
rozpatrzona dodanie instancji dla encji grupy. Fizycznie jest to nowa grupa, w bazie będzie
ona reprezentowana przez wiersz.
w
Parent
Information
przedmiot
Name
w
przedmiot_nazwa
przedmiot_instancja
przedmiot_opis
Dictionary
nazwa_dodana
w
grupa
dzien_tygodnia
grupa_nazwa
grupa_numer
czas_trwania
dzien_tygodnia_nazwa
da
.b
Name
Information
Name
Rys. 5. Schemat logiczny wraz z kategoriami dla encji, relacji i atrybutów
pl
s.
Pierwszym krokiem jest odszukanie encji grupy. Encja ta posiada kategorię Information
(nie zaznaczone na schemacie dla zachowania przejrzystości). Odszukane są wszystkie
relacje: grupa - przedmiot_instancja (Parent), grupa - dzien_tygodnia (Dictionary). Dla
encji przedmiot_instancja można wyróżnić następujące relacje: przedmiot_instancja przedmiot (Parent). Jeżeli chcemy zdefiniować nową grupę, to należy w pierwszym kroku
wybrać rodzica - jest nim encja przedmiot_instancja, wybierając przedmiot_instancja
musimy wybrać wiersz dla encji przedmiot. Kolejność kroków będzie następująca:
− KROK1: Informacje wstępne na temat dodania grupy.
− KROK2: Przedmiot - lista z wyborem przedmiotów, użytkownik wybiera jeden
przedmiot.
− KROK3: Lista z wyborem instancji przedmiotu dla wcześniej wybranego
przedmiotu(Rys.6.).
Rys. 6. Krok na stronie - wybór przedmiotu
170
− KROK4: Dwa pola edycyjne dla atrybutów: grupa_nazwa, a także grupa_numer.
ComboBox z wartościami atrybutu dzien_tygodnia_nazwa dla encji dzien_tygodnia,
ComboBox z wartościami atrybutu typ_grupy_nazwa dla encji typ_grupy (rys.7.).
w
w
w
Rys. 7. Kolejny krok na stronie - wpisywanie danych dla nowej grupy
− KROK5: Informacja o statusie, możliwość powrotu do poprzedniej strony, aby dodać
inną grupę dla tego samego przedmiotu (rys.8.).
da
.b
Rys. 8. Krok ostatni - możliwość dodania następnej grupy do wybranego przedmiotu
7 Wnioski i kierunki dalszej pracy
pl
s.
Przyszłe prace są związane z uwzględnieniem modelowania UML zamiast modyfikacji
schematu ERD. Należy zwrócić uwagę na rozszerzenie kategorii dla obiektów, a także
definiowaniem kategorii użytkownika.
Przedstawione rozwiązanie opiera się na tworzeniu GUI na podstawie zmodyfikowanego
schematu ERD, uzupełnionego o metadane przypisujące kategorie dla obiektów (encja,
relacja, atrybut). Należy pamiętać, że jest to szereg działań wspomagających, a nie
zastępujących całą pracę. Z doświadczeń wynika [9], że w taki sposób można
wygenerować około 85-95% wszystkich obiektów GUI. Przykładowo, dla 70 tabel, około 7
akcji dla każdej tabeli należy napisać około 500 wizardów po 3-7 stron każdy, co oznacza
około 2500 stron lub formatek. Po zastosowaniu automatycznej wizualizacji, czas
projektowania wydłuża się dwu lub trzykrotnie, natomiast generowanych jest około 450
z 500 potrzebnych wizardów.
Przedstawione podejście pozwala zaoszczędzić czas, a także uniezależnić się w znacznej
części od zmian w schemacie. Uniezależnienie się od zmian może być częściowo uzyskane
171
w
za pomocą wykorzystania modelu MVC (Model-View-Controller) opracowanego przez
IBM. Tutaj jest to jednak tylko w niewielkim wymiarze (zmiana nazwy atrybutu,
przeniesienie do innej tabeli). Po dodanie nowych atrybutów i encji należy zazwyczaj
przemodelować sporą liczbę stron lub formatek.
W aktualnej wersji bezpieczeństwo jest rozwiązane za pomocą prostych wpisów
dostępów do określonej strony dla każdej roli - posiada dostęp lub nie. Wbudowanych jest
domyślnie pięć ról: gość, student, prowadzący, administrator, superadmin.
Generowanie wizualizacji ze zmodyfikowanego schematu ERD jest odpowiednie
w określonych przypadkach. Podstawowym kryterium jest wielkość projektu: kilkanaście
do kilkudziesięciu encji. Przy większych projektach wartość pracy dodanej może
wykraczać poza poprawki potrzebne przy aktualizacji. Jeżeli konieczne jest użycie
zaawansowanego modelu bezpieczeństwa, stosowanie rozszerzonego modelowania jest
także mocno ograniczone. Należy zaznaczyć, że dla takiego projektu nie istnieje
dokumentacja automatycznie generowana - dlatego poprawki mogą być niezwykle trudne.
Przyszłe prace skupiają się na wykorzystaniu diagramów UML [6] [7] [8] przy
generowaniu wizualizacji, a także zaawansowanym bezpieczeństwie.
w
w
Literatura
5.
6.
7.
8.
9.
Allen S.: Modelowanie Danych, ISBN: 83-246-0184-8, 2006.
Marzec M.: JBuilder i bazy danych, ISBN: 83-7361-748-5, 2005.
Dokumentacja dla aplikacji JBuilder: http://www.borland.pl/jbuilder/
Roy-Daderman A., Koletzke P. Dorsey P.: Oracle JDeveloper 10g Handbook, ISBN:0-07225583-8, 2004.
Dokumentacja aplikacji JDeveloper: http://www.oracle.com/technology/products/jdev/
Wrycza S., Marcinkowski B., Wyrzykowski K.: Język UML 2.0 w modelowaniu systemów
informatycznych, ISBN: 83-7361-892-9, 2006.
Fowler M.: UML w kropelce, ISBN:83-87115-22-3, 2005.
Strona standardu UML: http://www.uml.org/
Strona Systemu Zarządzania Zajęciami: http://apas.polsl.pl/lms/
da
.b
1.
2.
3.
4.
pl
s.
172

pobierz plik referatu

Transkrypt

Podobne dokumenty

opisProjektu

bd - zajęcia1

Projektowanie baz danych. Zasady projektowania Projektowanie

Ac`łoEMIA EunoPA NIosrRA dr T omas z Stu dzieniecki

Relacyjny model bazy danych

Diagramy związków encji ERD Ćwiczenia w modelowaniu danych

Wykład 3

Projektowanie bazy danych, model związków encji

Inżynieria oprogramowania. - dr inż. Grzegorz Dec

gis_w05