Bazy danych 2. dr inż. Tadeusz Jeleniewski

Transkrypt

1 Wykład 4 Projektowanie bazy danych i procesów aplikacji Modelowanie reguł przetwarzania Środowisko przykładowego programu do modelowania reguł przetwarzania Reguły poprawności Bazy danych 2 W4 1

2 Projektowanie bazy danych i procesów aplikacji W procesie projektowania bazy danych można wyróżnić trzy etapy: 1. Sporządzenie dokumentacji reguł przetwarzania, niezbędnych do realizacji funkcji aplikacji. 2. Sporządzenie diagramu związków encji, wymaganych do obsługi procesów. 3. Stworzenie logicznego projektu bazy danych, niezbędnego do implementacji związków encji i reguł przetwarzania Bazy danych 2 W4 2

3 Przejścia pomiędzy poszczególnymi etapami można zautomatyzować przy pomocy narzędzi typu CASE. Upraszczają one proces tworzenia aplikacji klient serwer. W procesie projektowania aplikacji baz danych typu klient serwer system narzędziowy typu CASE powinien być narzędziem, a jego stosowanie powinno wymagać określonych umiejętności. Narzędzie nie będzie "myśleć" za projektanta. Nie uwolni go od planowania poprawnego rozwiązania problemu. Pomoże jedynie sprawnie wykonać to zadanie. Niezależnie od rodzaju stosowanych narzędzi, projektant musi dysponować podstawową wiedzą z zakresu teorii baz danych i funkcjonowania SZBD Bazy danych 2 W4 3

4 Systemy CASE przydatne do wspomagania procesów projektowania systemów baz danych powinny posiadać możliwość: - Modelowania reguł przetwarzania; kluczowe funkcje aplikacji są realizowane przez wzajemnie powiązane procesy. Model reguł przetwarzania stanowi formalną reprezentację tych procesów i ich wzajemnych powiązań. Istnieją narzędzia typu CASE przeznaczone specjalnie do modelowania procesów, np. pakiety firmy Sybase (obecnie SAP) Power Designer czy Silverrun BPM (Bussines Process Modeler) firmy CSA - patrz - Modelowania związków encji; większość projektantów baz danych korzysta z diagramów EER (Extended Entity Relationship). Umożliwiają one oddzielenie logicznej reprezentacji danych od ich fizycznej implementacji. Istnieją narzędzia CASE wspomagające modelowanie związków encji. - Tworzenia relacyjnego modelu danych; do dyspozycji projektanta są narzędzia, których możliwości wykraczają poza sporządzanie diagramów EER i obejmują zadania związane z projektowaniem całych logicznych schematów baz danych takie jak wymieniony wyżej pakiet Power Designer czy Silverrun RDM (Ralational Data Modeler) firmy CSA Bazy danych 2 W4 4

5 Modelowanie reguł przetwarzania Po zdefiniowaniu przeznaczenia i funkcji aplikacji projektant powinien sporządzić model reguł przetwarzania opisujący dokładniej te funkcje. Modele procesów mogą mieć np. postać diagramu przepływu danych (DFD data flow diagram). Ilustrują związki pomiędzy czterema podstawowymi elementami: procesami, obiektami zewnętrznymi, zbiorami i strumieniami danych. W tabeli pokazano przykładowe symbole graficzne elementów diagramu wykorzystywane w systemach narzędziowych serii Power Designer. Są to symbole wykorzystywane w stosowanych najczęściej modelach OMT (Object Modelling Technique) oraz Yourdon./DeMarco. Symbole graficzne tych elementów pokazano na następnym rysunku Bazy danych 2 W4 5

6 Element modelu Definicja Proces (Process) Obiekt zewnętrzny (External entity) Zbiór danych (Data store) Strumień danych (Data flow) Zadanie lub decyzja które aplikacja albo instytucja ma wykonać lub podjąć. Procesy są opisywane w kategoriach czynności realizowanych przy użyciu zasobów. Przykłady: zatrudnianie nowych pracowników, fakturowanie, przyjmowanie zamówień itp. Osoba, jednostka organizacyjna lub inny element, znajdujący się poza opisywaną instytucją lub aplikacją, ale współpracujący z nią. W modelowanym systemie są one źródłami lub odbiorcami informacji. Przykłady: klienci, najemcy, władze, rynek, itp. Dane generowane, wykorzystywane lub modyfikowane przez modelowany system. Przykłady: informacje o klientach, plany kont, księgi wieczyste, itp. Dane przepływające między obiektami zewnętrznymi, procesami i zbiorami. Przykłady: informacje udzielane klientom, zamówienia, reklamacje itp Bazy danych 2 W4 6

7 Strumień sterujący (Control flow) Rozdzielenie/łączenie (Split/merge) Zasób (Resource) Kwalifikator (Qualifier) Struktura danych (Data structure) Informacje i sygnały inicjujące, kontrolujące, przerywające działanie całego systemu; pochodzą na ogół od systemu nadrzędnego. Proces/miejsce rozdziału strumienia danych lub połączenia dwóch lub więcej strumieni danych w jeden. Element modelowanego systemu, wykorzystywany przez proces. Przykłady: serwery sieciowe, napędy pamięci taśmowej, osoby zajmujące określone stanowiska, artykuły biurowe, itp. Informacja dokładniej definiująca obiekt zewnętrzny, strumień, proces lub zbiór. Może np. informować, że reklamacje są przyjmowane zazwyczaj telefonicznie Szczegółowa informacja o danych zawartych w zbiorze Bazy danych 2 W4 7

8 Bazy danych 2 W4 8

9 Aby sporządzić model procesów (diagram przepływu danych) zachodzących w środowisku projektowanego systemu należy: 1) Określić niezbędne obiekty zewnętrzne, procesy, strumienie i zbiory. 2) Zadecydować o tym, jakie związki mają zachodzić pomiędzy tymi elementami. 3) Sporządzić diagram, obrazujący te elementy i związki zachodzące między nimi Bazy danych 2 W4 9

11 W przykładowym systemie WYNAJEM można przyjąć, na podstawie analizy procesów zachodzących w środowisku, następujące założenia: - model wymaga co najmniej jednego obiektu zewnętrznego jest nim potencjalny najemca, - przetwarzanie umów najmu i wykonywanie umów najmu będą dwoma oddzielnymi procesami, - firma wynajmująca nieruchomości rejestruje zgłoszenia, w tym również telefoniczne od potencjalnych najemców; jest też zainteresowana przechowywaniem informacji o najemcach, umowach najmu i nieruchomościach. - w systemie powinny znaleźć się cztery zbiory danych, które będą zawierać informacje o zgłoszeniach, najemcach, nieruchomościach i umowach najmu Bazy danych 2 W4 11

12 Przepływy danych pomiędzy wymienionymi elementami powinny spełniać następujące założenia: - potencjalni najemcy nawiązują kontakt z pracownikiem firmy wynajmującej i uzyskują informacje o dostępnych nieruchomościach lub zawierają umowę najmu, - pracownik rejestruje każde odebrane zgłoszenie, niezależnie od tego, czy w jego wyniku zostaje zawarta umowa najmu, czy nie, - po zweryfikowaniu umowa najmu trafia do innego pracownika odpowiedzialnego za jej wykonanie, - informacje o najemcy, uzyskane podczas zawierania umowy są rejestrowane, - rejestruje się również wykonane umowy Bazy danych 2 W4 12

13 Reguły poprawności Niektóre systemy narzędziowe klasy CASE (np. Power Designer) pozwalają określać na etapie modelowania reguł przetwarzania (analizy procesów informacyjnych w środowisku) tzw. reguły poprawności (reguły biznesowe - ang. business rules). Reguły te są potem wykorzystywane m. in. do dokumentowania projektu oraz do tworzenia procedur wyzwalaczy (ang. triggers). Regułą biznesową nazywa się przepis, regułę, zależność, która rządzi przepływem danych w modelowanym środowisku. Regułami biznesu mogą być przepisy obowiązującego prawa, wymagania inwestora (zleceniodawcy) lub wewnętrzne zależności systemowe Bazy danych 2 W4 13

14 Bardzo często formułowanie reguł poprawności rozpoczyna się od prostego stwierdzenia typu np. potencjalny najemca nieruchomości nawiązuje kontakt telefoniczny lub bezpośredni z pracownikiem firmy wynajmującej nieruchomości. W procesie projektowania systemu są one rozwijane do postaci szczegółowych wyrażeń. Reguły biznesowe służą do prowadzenia i dokumentowania procesu tworzenia modelu systemu. Przykładowa reguła potencjalny najemca nieruchomości nawiązuje kontakt telefoniczny lub bezpośredni z pracownikiem firmy wynajmującej nieruchomości może pomóc w graficznej reprezentacji odpowiedniego przepływu informacji pomiędzy najemcą a firmą wynajmującą. Reguły biznesowe uzupełniają model graficzny o informacje, który nie da się w prosty sposób zaprezentować graficznie. Niektóre reguły specyfikują szczegóły fizyczne w postaci ograniczeń i wyrażeń. Takie wyrażenia nie mają swojej reprezentacji graficznej. Wyróżnić można cztery typy reguł biznesowych, których opis i przykłady pokazano w tabeli Bazy danych 2 W4 14

15 Typ reguły Opis Przykład Definicja Fakt Formuła Ograniczenie Charakterystyki lub własności obiektu w systemie informacyjnym Pewność lub występowanie w systemie informacyjnym Obliczenie wykonywane w systemie informacyjnym Ograniczenie wartości danej w systemie informacyjnym Klient jest osobą identyfikowaną za pomocą nazwiska i adresu Klient może złożyć jedno lub więcej zamówień Łączna kwota zamówienia jest sumą wszystkich pozycji zamówienia Łączna kwota zamówień określonego klienta nie może być większa niż kwota przeznaczona przez klienta na realizację zamówienia Bazy danych 2 W4 15

16 Przed utworzeniem reguł biznesowych projektant musi odpowiedzieć na następujące pytania: - Na jakie problemy w modelowanym środowisku należy zwrócić uwagę? - Czy są jakieś procedury, których musi przestrzegać mój system? - Czy są jakieś specjalne przesłanki, które określają zakres mojego projektu? - Czy są jakieś ograniczenia możliwości systemu? - Jak można opisać każdą z tych procedur, przesłanek i ograniczeń? - Do jakiej grupy można zakwalifikować te opisy: do definicji, faktów, formuł lub ograniczeń? Bazy danych 2 W4 16

18 Środowisko przykładowego programu do modelowanie reguł przetwarzania Przykładowy program wspomagający proces modelowania reguł przetwarzania (jedna z opcji narzędzia Power Designer) jest typowym programem z interfejsem graficznym (GUI). Pozwala on utworzyć schemat przepływu danych pomiędzy obiektami zewnętrznymi, procesami i zbiorami danych systemu użytkowego. Pomaga określić: - domeny (typy i zbiory wartości) danych przechowywanych w bazie, - dane przesyłane pomiędzy poszczególnymi obiektami modelu i kierunki ich przepływu, - role i znaczenie obiektów modelu i elementów zbiorów danych, - ograniczenia i reguły obliczania wartości tzw. danych wyliczanych, - uprawnienia procesów (użytkowników) bazy do wykonywania określonych operacji (tworzenie, czytanie, poprawianie, usuwanie) na zbiorach danych i na poszczególnych elementach zbiorów Bazy danych 2 W4 18

20 W każdej fazie tworzenia modelu możliwa jest automatyczna kontrola jego poprawności. Program generuje automatycznie dokumentację modelu reguł przetwarzania o określonym przez projektanta standardowym lub niestandardowym poziomie szczegółowości Bazy danych 2 W4 20

26 Konceptualny i fizyczny model danych Na podstawie modelu reguł przetwarzania programy - narzędzia CASE, np. Power Designer pozwala utworzyć tzw. konceptualny model danych (CDM). Wykorzystując zaimportowane z etapu tworzenia modelu BPM słowniki domen, reguł biznesowych, zbiorów danych i obiektów zewnętrznych określa się zbiory encji oraz ich atrybuty. Pomiędzy tak zdefiniowanymi zbiorami encji kreśli się relacje o określonych własnościach. Wszystko to odbywa się oczywiście w trybie graficznym z wykorzystaniem technik OLE oraz Drag and Drop. Dalej pokazano symbole graficzne powiazań wykorzystywane na schematach modeli CDM Bazy danych 2 W4 26

28 Symbole związków pomiędzy zbiorami encji stosowane w modelu konceptualnym (CDM): - jeden do jednego (po stronie docelowej musi wystąpić element zależny), - jeden do wielu (po stronie źródłowej i docelowej nie muszą wystąpić elementy), - wiele do jednego (po stronie docelowej musi wystąpić dokładnie jeden element zależny) - wiele do wielu (po stronie źródłowej i docelowej nie muszą wystąpić odpowiadające sobie elementy). Dalej pokazano kolejne etapy projektowania i generowania prostej bazy danych, od modelu konceptualnego poprzez model fizyczny do utworzenia skryptu SQL zawierającego definicje obiektów bazy oraz skryptu z danymi testowymi Bazy danych 2 W4 28