Wykład 6 Zagadnienia związane z projektowaniem systemów informacyjnych

Prezentacja na temat: "Wykład 6 Zagadnienia związane z projektowaniem systemów informacyjnych"— Zapis prezentacji:

1 Wykład 6 Zagadnienia związane z projektowaniem systemów informacyjnych

2 Treść wykładu model obiektowy - model relacyjny
cechy modelu relacyjnego integracja systemów obiektowych z systemami relacyjnymi struktura systemów obiektowo-relacyjnych sposoby odwzorowania modelu obiektowego w model relacyjny normalizacja baz danych prototypowanie realizacja i wdrożenie systemu informacyjnego utrzymanie systemu informacyjnego zarządzanie projektem kontrola jakości

3 Model obiektowy czy model relacyjny
zmniejszenie dystansu pomiędzy modelowaniem rzeczywistości a ujmowaniem procesów oraz danych występujących w rzeczywistości model relacyjny ogranicza odwzorowanie dziedziny przedmiotowej środkami implementacyjnymi ograniczona semantyka danych model obiektowy przybliża semantykę danych świata rzeczywistego schemat relacyjny traci część semantyki danych

4 Model obiektowy kontra model relacyjny
model relacyjny przegrał z modelem obiektowym w sferze modelowania konceptualnego szereg systemów dojrzałych technicznie i funkcjonalnie posiada odstępstwa od systemów obiektowych pomost pomiędzy systemami opartymi na modelach relacyjnych i modelach obiektowych systemy relacyjne uzupełniane są o interfejsy zawierające pojęcia obiektowe systemy obiektowe wzbogacane o perspektywy relacyjnych baz danych języki relacyjne SQL zmierzają w stronę języków obiektowych

5 Cechy modelu relacyjnego
relacja jako ustalony konstruktor danych rozszerzany przez twórców systemów relacyjnych brak bezpośredniego modelowania obiektów złożonych, informacje o obiektach złożonych są rozproszone w krotkach wielu tablic uzyskanie informacji o obiektach złożonych następuje w zapytaniach SQL co zwiększa złożoność oraz czas wykonywania zapytań brak wyspecjalizowanych mechanizmów realizacji powiązań między danymi brak mechanizmów przechowywania danych proceduralnych wykraczających poza strukturę relacyjną perspektywy, procedury, aktywne reguły brak mechanizmów hermetyzacji oddzielenia implementacji od specyfikacji

6 Cechy modelu relacyjnego c. d.
zanurzenie metod dostępu do danych w uniwersalnych językach programowania właściwości relacyjnych struktur danych powodują zwiększenie kodu aplikacji połączenie języka SQL z językiem programowania powoduje dodatkowo zwiększenie długości kodu wykorzystanie matematycznych właściwości relacji model relacyjny opierał się na założeniu o niezależności od warstwy fizycznej danych

7 Sytuacja obecna systemy relacyjne dla większości przypadków są wystarczające - redukcja zainteresowania systemami obiektowymi nadal istnieją duże nakłady na systemy relacyjne wiele aplikacji obiektowych musi zostać przystosowana do pracy z danymi pozostałymi model obiektowy umożliwia zmniejszenie nakładów związanych z pielęgnacją oprogramowania błędne kojarzenie relacyjnych baz danych z interfejsami obiektowymi jako obiektowe bazy danych

8 Sytuacja obecna c. d. wiele aplikacji wykorzystuje warstwę trwałych obiektów aplikacja dokonuje jedynie operacji na danych poprzez zdefiniowany interfejs, który stanowi odizolowanie od warstwy bazy danych aplikacje obiektowe zawierające odwołanie do relacji między obiektami są bardziej powolne szybkość złączeń klucze nie powinny mieć znaczenia w dziedzinie przedmiotowej zmiany w dziedzinie przedmiotowej klucze nie powinny być złożone

9 Integracja systemów obiektów z systemami relacyjnymi
rynek zastosowań rozwiązań technologicznych jest w miarę stabilny opór przed zmianami technologii systemy relacyjne opanowały większość dziedzin przedmiotowych

10 Integracja systemów obiektowych z systemami relacyjnymi c.d.
system relacyjny jako back-end nad systemem relacyjnym budowany jest front-end w postaci interfejsów do obiektów złożonych, mechanizmów zarządzania klasami oraz dziedziczeniem obiektowe perspektywy nad strukturą relacyjną odwzorowanie obiektowego schematu w struktury relacyjne niemożliwość odwzorowania wszystkich szczegółów schematu obiektowego konieczność wprowadzenia dodatkowych elementów do schematu bazy danych kompromis pomiędzy zajętością pamięci a czasem dostępu - normalizacja i denormalizacja

11 Struktura systemów obiektowo-relacyjnych
graficzny interfejs użytkownika warstwa programów aplikacyjnych łącze między warstwą programów aplikacyjnych a warstwą obiektów biznesowych w postaci języków C++, Java czy Smaltalk warstwa obiektów biznesowych warstwa odwzorowania obiektów na relacje łącze między systemem zarządzania bazą danych a warstwą obiektów biznesowych w postaci języka SQL system zarządzania bazą danych relacyjna baza danych

12 brak przechowywania wielu wartości jednego atrybutu
Podstawowe problemy przechodzenia z modelu konceptualnego obiektowego na konkretny model systemu zarządzania bazą danych brak przechowywania wielu wartości jednego atrybutu brak mechanizmów dziedziczenia brak mechanizmów wariantowości brak możliwości zagnieżdżania danych każda tablica musi posiadać klucz powiązania między obiektami są implementowane jako relacje oraz tablice z kluczami krotki powinny być identyfikowane poprzez osobny klucz należący do tablicy rozmiar krotek jest ograniczony charakterystyka ilościowa danych i funkcji unikanie redundancji - normalizacja wymagania wydajnościowe

13 Sposoby odwzorowywania modelu obiektowego w model relacyjny
atrybuty złożone atrybuty złożone są odwzorowywane w odrębne tablice w przypadku, kiedy wartości mogą być identyczne i kolejność wartości jest istotna wprowadza się dodatkowy atrybut stanowiący klucz ustalający porządek odwzorowanie związków asocjacji dla liczności 1:1 implementowana jest tylko jedna tablica dla liczności 1:n implementowane są dwie tablice dla liczności n:m implementowane są trzy tablice

14 Odwzorowanie złożonych obiektów
spłaszczenie struktury obiektów poprzez zamianę atrybutów złożonych na proste, usunięcie powtarzalnych atrybutów oraz stosowanie różnych form normalizacji reprezentacja obiektu złożonego w wielu tablicach informacja o złożonym obiekcie jest przechowywana w strukturze relacyjnej z wykorzystaniem mechanizmów integralności referencyjnej zasada integralności mówi o tym, że dla każdego klucza obcego musi istnieć krotka posiadająca taki sam klucz główny integralność referencyjna nie jest w stanie odwzorować całej semantyki obiektów złożonych - korzeń obiektu, hermetyzacja obiektu, semantyka operacji na obiektach

15 Odwzorowanie metod i operacji
w modelu relacyjnym nie istnieją mechanizmy bezpośredniego odwzorowania metod oraz operacji operacje oraz metody są odwzorowywane na poziomie programów aplikacyjnych z wykorzystaniem klasycznych lub obiektowych języków programowania, programy te dedykowane są do obsługi konkretnych tablic metody mogą być odwzorowywane z wykorzystaniem procedur baz danych SQL oraz aktywnych metod odwzorowanie polimorfizmu, przesłaniania i hermetyzacji jest jedynie możliwe poprzez jawną selekcję różnych przypadków klas

16 Metody podejścia do braku dziedziczenia
jedna tablica dla całej hierarchii klas metoda polegająca na zsumowaniu wszystkich występujących atrybutów i powiązań w drzewie, dodanie opcjonalnego deskryptora opisującego wariant użycie tablic dla każdej konkretnej klasy metoda polegająca na usunięciu klas abstrakcyjnych i przesunięciu ich atrybutów do klas konkretnych użycie tablicy dla każdej klasy metoda polegająca na zamianie generalizacji na powiązania łączące nadklasę z wszystkimi klasami podrzędnymi

17 Normalizacja baz danych
dekompozycja tablic na dwie lub więcej w celu uniknięcia niekorzystnych własności bazy danych redundancja danych oraz anomalie aktualizacyjne zależności funkcyjne między atrybutami wartość atrybutu A2 zależy od wartości atrybutu A1, jeżeli dla każdej wartości A2 można przyporządkować dokładnie jedną wartość atrybutu A1; A2 = f(A1) każdy atrybut jest funkcyjnie zależny od klucza

18 Postacie normalne druga postać normalna 2PN
nie ma atrybutów, które zależą funkcyjnie od klucza trzecia postać normalna 3PN usunięcie niepełnej zależności funkcjonalnej czwarta postać normalna 4PN usunięcie wielokrotnych wielowartościowych zależności funkcjonalnych piąta postać normalna 5PN usunięcie połączeniowej zależności funkcjonalnej nie wynikającej z zależności atrybutów od klucza

19 Denormalizacja baz danych
odwrotność normalizacji połączenie dwóch lub więcej tablic relacyjnych w jedną denormalizacja niska efektywność operacji złączenia usunięcie skomplikowanej struktury schematu bazy danych wykonanie zewnętrznego złączenia dwóch lub więcej tablic

20 Dobór kluczy dla każdej klasy dobierany jest atrybut lub kombinacja atrybutów, które mają stanowić klucz w przypadku braku atrybutów kandydatów powoływany jest sztuczny identyfikator dla klasy klucz nie powinien mieć znaczenia w dziedzinie przedmiotowej w większości przypadków klucz powinien być generowany automatycznie klucze jako wąskie gardło dla transakcji

21 Cele prototypowania budowa architektury prototypu
zaprezentowanie użytkowych aspektów systemu informacyjnego świadoma akceptacja przyszłych użytkowników zbudowanie struktury oprogramowania w postaci modułów budowa prototypu operacyjnego systemu informacyjnego funkcje użytkowe zakres informacyjny cechy operacyjne prototypu bazy danych oraz oprogramowania dokumentacja

22 Prototypowanie systemu informacyjnego - składniki
prototyp architektury projekt architektury systemu informacyjnego: hierarchiczna struktura funkcji, dodatkowe funkcje użytkowe, projekt interfejsu użytkownika: wygląd ekranów, diagnostyka, pomoc prototyp operacyjny prototyp baz danych: schemat bazy danych, aktywne ograniczenia i reguły, procedury bazy danych, konwersje zbioru danych prototyp oprogramowania użytkowego: struktura sterująca, moduły wejściowe i wyjściowe, dokumentacja użytkowa testowanie, weryfikacja i dokumentacja prototypu

23 Przygotowanie do realizacji i wdrożenia - składniki
dostosowanie przedsiębiorstwa wdrożenie systemu zmiany w systemie zarządzania zmiany w systemie organizacyjnym przygotowanie kadry przedsiębiorstwa kadra kierownicza pozyskiwanie i szkolenie kadry informatycznej kadra użytkowników przygotowania techniczne zakup i instalacja sprzętu komputerowego zakup oprogramowania systemowego i narzędziowego zakup gotowego oprogramowania użytkowego infrastruktura techniczna

24 Wdrożenie - cele przygotowanie użytkowników końcowych
szkolenie kadry kierowniczej administratorów systemu posługiwanie się modułami w systemie w sytuacjach poprawnych oraz awaryjnych zasady eksploatacji systemu oraz administrowania bazą danych dokumentacja użytkownika systemu przygotowanie systemu do migracji danych sprawdzenie systemu w warunkach rzeczywistej pracy systemu ostateczne wdrożenie systemu informacyjnego

25 Wdrożenie systemu informacyjnego - składniki
przygotowanie kadry użytkowników szkolenie kadry zarządzającej szkolenie użytkowników szkolenie administratorów zasady eksploatacji systemu informacyjnego oraz administrowania bazą danych autoryzacja dostępu ochrona integralności danych ograniczenia eksploatacyjne dokumentacja eksploatacyjna serwis użytkownika

26 Wdrożenie systemu informacyjnego - składniki c.d.
przygotowanie systemu informacyjnego do eksploatacji migracja danych do bazy danych próbne uruchomienie systemu w warunkach rzeczywistych wprowadzenie systemu do bieżącej eksploatacji weryfikacja systemu informacyjnego testy akceptacyjne badania efektywności badania wydajnościowe

27 Wdrożenie - spodziewane wyniki
przeszkolona kadra użytkowników w zakresie posługiwania się modułami systemu dokumentacja eksploatacji systemu zasady administrowania bazą danych zasady eksploatacji systemu dokumentacja użytkownika system informacyjny wprowadzony do eksploatacji system informacyjny całkowicie zweryfikowany i przetestowany

28 Utrzymanie systemów informacyjnych - cele
monitorowanie przebiegu użytkowania planowanie i organizacja serwisu technicznego weryfikacja procedur i algorytmów utrzymanie bazy danych organizacja i szkolenie nowych użytkowników i kadry obsługującej system rozwój i modyfikacja systemu nowe wymagania zmiany technologii informatycznej zmiany otoczenia

29 Utrzymanie systemów informacyjnych - składniki
użytkowanie systemów informacyjnych monitorowanie pracy serwis techniczny usuwanie błędów weryfikacja algorytmów utrzymywanie bazy danych reorganizacja kadry szkolenie kadry modernizacja i rozwój systemu informacyjnego nowe wymagania techniczne nowe wymagania użytkowe nowe wymagania strategiczne odwrotna inżynieria systemów informacyjnych reorganizacja procesów biznesu

30 Zarządzanie projektem - składniki
planowanie ustalanie celów przedsięwzięcia ustalanie listy czynności organizacja zasobów ocena pracochłonności i kosztorysowanie analiza ryzyka ustalenie zasad zarządzania projektem kontrola monitorowanie realizacji przedsięwzięcia ocena wyników - harmonogram ocena wyników - budżet rewizja czynności korekty organizacyjne

31 Kontrola jakości zapewnienie jakości
organizacja procesu kontroli jakości: polityka kierownictwa, system kontroli jakości, zespół kontroli jakości wdrożenie metodyki: zarządzanie projektem, fazy, czynności, kroki, role, techniki, narzędzia polityka kadrowa: ocena kwalifikacji, szkolenia, perspektywy, komunikacja, identyfikacja, współdzielenie monitorowanie - spełnienie norm jakości przedsięwzięcia informatycznego stosowanie metodyki i standardów kontrola formalna kontrola merytoryczna testowanie kontrola zmian weryfikacja metodyki

32 Zarządzanie projektem
Komisja Kierująca Klient Konsultant Zarząd, sponsorzy projektu, działy specjalistyczne. BPI- Doradztwo Zarządzanie projektem Kontrola jakości Użytkownik specjaliści w aplikacji wsparcie techniczne trening/ nadzór wdrożenie procesów gospodarczych w ramach funkcji SI parametryzacja aplikacji interfejsy prototyp definicja wymagań zmiany w organizacji przedsiębiorstwa organizacja przebiegu projektu test odbioru Architektura SI Architektura bazy danych Architektura C/S Architektura sieci

33 Plan projektu - przykład
2000 III IV V VI VII VII IX X XI XII I II Inicjacja projektu Szkolenia dla różnych grup pracowników Projekt/Prototyp Implementacja Testowanie systemu Przygotowanie do wdrożenie Migracja Start systemu

34 Przyczyny niepowodzeń w realizacji projektu
brak umiejętności zarządzania projektami zła kontrola jakości szczególnie we wczesnych fazach cyklu życia systemu dynamika zmian wymagań użytkowników końcowych czynniki nie związane z informatyką