Inżynieria oprogramowania wykład V Faza analizy wprowadzenie Analiza strukturalna modelowanie związków encji

Transkrypt

1 Inżynieria oprogramowania wykład V Faza analizy wprowadzenie Analiza strukturalna modelowanie związków encji prowadzący: dr hab. inż. Krzysztof Bartecki, prof. PO

2 Faza analizy systemowej (modelowania) Wymagania Projektowanie Implementacja Testowanie Konserwacja Strategiczna Analiza Instalacja Dokumentacja Jej celem jest udzielenie odpowiedzi na pytanie: jak system ma działać? W wyniku fazy analizy otrzymujemy logiczny model systemu, opisujący sposób realizacji przez system postawionych wymagań, lecz abstrahujący jeszcze od szczegółów implementacyjnych. K. Bartecki, Inżynieria oprogramowania, V/2

3 Główne cechy dobrego modelu analitycznego opisuje na wysokim poziomie abstrakcji wszystkie istotne cechy tworzonego systemu informatycznego, opisany jest za pomocą notacji zgodnej z określoną konwencją, zbudowany jest przy użyciu dobrze znanych narzędzi (CASE), bazuje na hierarchicznej dekompozycji funkcji systemu, używany jest do wnioskowania o przyszłym oprogramowaniu,. unika terminologii implementacyjnej. K. Bartecki, Inżynieria oprogramowania, V/3

4 Dziedzina problemu i zakres odpowiedzialności systemu a zakres modelu analitycznego Tworzony system informatyczny będzie obejmował jedynie pewien fragment większej całości, zwanej dziedziną problemu. Przykłady dziedzin problemu: działalność firmy rachunkowej, funkcjonowanie wydziału firmy farmaceutycznej, wizualizacja informacji geograficznej. Fragment dziedziny problemu, który będzie objęty przez tworzony system informatyczny, nazywany jest zakresem odpowiedzialności systemu. K. Bartecki, Inżynieria oprogramowania, V/4

5 Dziedzina problemu (zakres działalności firmy) Model analityczny Zakres odpowiedzialności systemu Model analityczny z reguły wykracza poza zakres odpowiedzialności systemu, a czasem nawet poza dziedzinę problemu, gdyż: ujęcie w modelu pewnych fragmentów dziedziny problemu nie będących częścią budowanego systemu czyni model bardziej zrozumiałym, na etapie modelowania może nie być jasne, które elementy będą realizowane przez tworzony system informatyczny a które np. ręcznie. K. Bartecki, Inżynieria oprogramowania, V/5

6 Wiele systemów informatycznych w prosty sposób automatyzuje wykonywanie czynności wykonywanych do tej pory ręcznie w tym przypadku tworzenie modelu systemu informatycznego można utożsamiać z modelowaniem struktury oraz sposobu funkcjonowania danej firmy/organizacji. W innych przypadkach wdrożenie systemu informatycznego w istotny sposób zmienia dotychczasową dziedzinę problemu w tym przypadku celem analizy jest stworzenie modelu fragmentu dziedziny problemu zmodyfikowanej przez działanie projektowanego systemu. K. Bartecki, Inżynieria oprogramowania, V/6

7 Notacje używane w fazie analizy Do opisu modelu stosuje się następujące rodzaje notacji: język naturalny, notacje graficzne, specyfikacje częściowo ustrukturalizowany zapis tekstowy i numeryczny. Szczególną rolę pełnią tutaj notacje graficzne inżynieria oprogramowania wzoruje się tutaj na innych dziedzinach nauki (mechanice, elektronice), w których notacje graficzne są od dawna stosowane. K. Bartecki, Inżynieria oprogramowania, V/7

8 Metody analizy systemowej podział STRUKTURALNE Wyróżniają w systemie dwa rodzaje składowych: pasywne (dane), aktywne (operacje funkcje). OBIEKTOWE Opisują system jako układ współdziałających z sobą obiektów, łączących w jedną całość dane i operacje na tych danych wykonywane. K. Bartecki, Inżynieria oprogramowania, V/8

9 Analiza strukturalna Analiza strukturalna zaczyna się od budowy dwóch różnych modeli: modelu danych, będącego opisem pasywnej części systemu, modelu funkcji, opisującego aktywną część systemu. Zwolennicy analizy strukturalnej twierdzą, że budowa dwóch oddzielnych modeli ułatwia zrozumienie różnych aspektów systemu. Krytycy zwracają uwagę na to, że integracja tych dwóch modeli może być bardzo trudna. K. Bartecki, Inżynieria oprogramowania, V/9

10 Model danych modelowanie związków encji Modelowanie związków encji polega na identyfikowaniu w analizowanym przedsiębiorstwie rzeczy ważnych (tzw. encji), własności tych rzeczy (czyli tzw. atrybutów) oraz sposobów, jakimi te encje są ze sobą powiązane (czyli tzw. związków). Cele modelowania związków encji: Dostarczenie modelu potrzeb informacyjnych przedsiębiorstwa, niezależnego od sposobu przechowywania danych i od metod dostępu do nich. W praktyce inżynierskiej model związków encji stanowi konceptualny, wstępny model bazy danych. K. Bartecki, Inżynieria oprogramowania, V/10

11 Definicja encji Encja (ang. entity) jest rzeczą lub obiektem, rzeczywistym lub wyobrażonym, mającym dla nas znaczenie, o którym informacje muszą być znane lub przechowywane. Nazwa encji to rzeczownik w liczbie pojedynczej, na diagramie zapisany wielkimi literami. Przykłady encji i ich instancji (czyli wystąpień): PORT LOTNICZY (LOTNISKO) np. Okęcie Balice Pyrzowice CZYTELNIK np. Józef Kowalski Zbigniew Kępski Adam Nowak ZAMÓWIENIE np. 1134/ / /16 K. Bartecki, Inżynieria oprogramowania, V/11

12 Atrybut encji (ang. entity attribute) jest dowolnym szczegółem, służącym do opisywania, identyfikowania, klasyfikowania, określania ilości lub wyrażania stanu encji. Atrybut encji jest dowolnym opisem mającym znaczenie dla encji. Nazwa atrybutu musi być podana w liczbie pojedynczej. Przykłady encji i ich wybranych atrybutów: SAMOLOT producent nazwa typu samolotu liczba miejsc numer rejestracyjny data produkcji nazwa samolotu KARTA KREDYTOWA data wydania ważna od ważna do numer WYPOŻYCZENIE numer kolejny liczba pozycji data wypożyczenia data zwrotu K. Bartecki, Inżynieria oprogramowania, V/12

13 Atrybut musi znajdować się przy encji, którą opisuje Czy np. nazwa towaru powinna być atrybutem encji TOWAR, ZAMÓWIENIE czy KLIENT? Czy np. numer siedzenia powinien być atrybutem encji BILET, MIEJSCE czy SAMOLOT? Czy np. numer rejestracyjny powinien być atrybutem encji POJAZD czy WŁAŚCICIEL? TOWAR nazwa towaru MIEJSCE numer siedzenia POJAZD numer rejestracyjny K. Bartecki, Inżynieria oprogramowania, V/13

14 Instancja encji to konkretne wystąpienie danej encji. Każdej instancji encji przypisane są określone wartości jej atrybutów. Przykładowe instancje (wystąpienia) encji SAMOLOT z wartościami atrybutów: SAMOLOT SAMOLOT SAMOLOT Boeing SP-EEA 2004 Paderewski Boeing SP-EEB 2006 Chopin Boeing SP-EEK 2006 brak nazwy K. Bartecki, Inżynieria oprogramowania, V/14

15 Może się zdarzyć, że atrybut przyjmuje określoną wartość tylko przez pewien czas, dopiero po pewnym czasie, lub wartość ta może nie być osiągalna. Takie atrybuty nazywamy opcjonalnymi (o), w odróżnieniu od atrybutów wymaganych (*), dla których wartości muszą być podane. Przykłady: SAMOLOT * producent * nazwa typu samolotu * liczba miejsc * numer rejestracyjny * data produkcji o nazwa samolotu WYPOŻYCZENIE * numer kolejny * liczba pozycji * data wypożyczenia o data zwrotu CZYTELNIK * nazwisko * imię * imię ojca * miejscowość * ulica * nr domu o nr mieszkania * data zapisania o data wypisania K. Bartecki, Inżynieria oprogramowania, V/15

16 Identyfikator encji Każda encja musi być jednoznacznie identyfikowalna, aby każdą instancję encji można było odróżnić od wszystkich innych jej instancji. Rolę identyfikatora encji (#) może pełnić: pojedynczy atrybut (wymagany), kombinacja kilku wybranych atrybutów (wszystkie wymagane). SAMOLOT # numer rejestracyjny * producent * nazwa typu samolotu * liczba miejsc * data produkcji o nazwa samolotu CZYTELNIK # nazwisko # pierwsze imię # drugie imię * data urodzenia * data zapisania o data wypisania K. Bartecki, Inżynieria oprogramowania, V/16

17 Związek encji Związek encji jest nazwanym, istotnym powiązaniem, istniejącym między dwoma encjami. W szczególnym przypadku związek może być powiązaniem tej samej encji ze sobą (tzw. związek rekurencyjny, omawiany dalej). Przykładowa notacja związku encji: ENCJA A opcjonalny (kółko) wymagany (kreska) ENCJA B wiele (kurza stopka) jeden (linia) K. Bartecki, Inżynieria oprogramowania, V/17

18 Jak czytać notację związków encji? Przykład: BILET # nr biletu * cena : wystawiony dla widnieje na PASAŻER # nr dowodu * nazwisko * imię nazwy ról Każdy BILET musi być wystawiony na jednego i tylko jednego PASAŻERA. (Nie może być biletów pustych, tzn. nie wystawionych na nikogo oraz biletów wystawionych na więcej niż jednego pasażera) Każdy PASAŻER może widnieć na wielu BILETACH. (Mogą istnieć pasażerowie, których nazwiska nie widnieją na żadnym bilecie, mogą istnieć tacy, których nazwiska widnieją na jednym lub wielu biletach) K. Bartecki, Inżynieria oprogramowania, V/18

19 Poglądowy diagram ilustrujący związek między encjami BILET i PASAŻER BILET PASAŻER K. Bartecki, Inżynieria oprogramowania, V/19

20 Związek zależny (encja zależna, encja słaba) Każda encja musi posiadać identyfikator. Niekiedy jednak atrybuty danej encji nie wystarczają do zidentyfikowania instancji (wystąpienia) tej encji. W tym przypadku na identyfikator danej encji mogą składać się zarówno jej własne atrybuty, jak również atrybuty (identyfikatory) innej encji (lub kilku innych encji), z którą dana encja tworzy związek. Encję nie posiadającą swojego identyfikatora nazywamy encją słabą, zaś związek jaki tworzy ona z encją od której pobiera identyfikator związkiem zależnym. K. Bartecki, Inżynieria oprogramowania, V/20

21 Przykład związku zależnego ZADANIE # numer zadania * nazwa zadania * koszt zadania realizowane w ramach symbol związku zależnego złożony z PROJEKT # numer projektu * nazwa projektu * data rozpoczęcia o data zakończenia PROJEKT może składać się z wielu zadań. Koszt ZADANIA o danym numerze zadania zmienia się w zależności od PROJEKTU, w ramach którego jest ono wykonywane. Aby zidentyfikować konkretne ZADANIE w ramach określonego PROJEKTU (i w ten sposób określić koszt tego ZADANIA), należy podać zarówno numer zadania, jak również numer projektu, w ramach którego jest ono realizowane. Na identyfikator encji ZADANIE składają się zatem 2 atrybuty: numer zadania oraz numer projektu, będący identyfikatorem encji PROJEKT. K. Bartecki, Inżynieria oprogramowania, V/21

22 Przykłady notacji związków wiele do jednego PRACOWNIK WYDZIAŁ Każdy PRACOWNIK może pracować w jednym WYDZIALE. Każdy WYDZIAŁ może zatrudniać wielu PRACOWNIKÓW. PRACOWNIK WYDZIAŁ Każdy PRACOWNIK może pracować w jednym WYDZIALE. Każdy WYDZIAŁ musi zatrudniać jednego lub wielu PRACOWNIKÓW. PRACOWNIK WYDZIAŁ Każdy PRACOWNIK musi pracować w dokładnie jednym WYDZIALE. Każdy WYDZIAŁ może zatrudniać wielu PRACOWNIKÓW. PRACOWNIK WYDZIAŁ Każdy PRACOWNIK musi pracować w dokładnie jednym WYDZIALE. Każdy WYDZIAŁ musi zatrudniać jednego lub wielu PRACOWNIKÓW. K. Bartecki, Inżynieria oprogramowania, V/22

23 Przykłady notacji związków jeden do jednego ZESPÓŁ PROJEKT Każdy ZESPÓŁ może pracować nad jednym PROJEKTEM. Każdy PROJEKT może mieć przypisany jeden ZESPÓL. ZESPÓŁ PROJEKT Każdy ZESPÓŁ może pracować nad jednym PROJEKTEM. Każdy PROJEKT musi mieć przypisany dokładnie jeden ZESPÓL. ZESPÓŁ PROJEKT Każdy ZESPÓŁ musi pracować nad dokładnie jednym PROJEKTEM. Każdy PROJEKT może mieć przypisany jeden ZESPÓL. K. Bartecki, Inżynieria oprogramowania, V/23

24 Przykłady związków wiele do wielu PRACOWNIK WYDZIAŁ Każdy PRACOWNIK może pracować w wielu WYDZIAŁACH. Każdy WYDZIAŁ może zatrudniać wielu PRACOWNIKÓW. PRACOWNIK WYDZIAŁ Każdy PRACOWNIK może pracować w wielu WYDZIAŁACH. Każdy WYDZIAŁ musi zatrudniać jednego lub wielu PRACOWNIKÓW. PRACOWNIK WYDZIAŁ Każdy PRACOWNIK musi pracować w jednym lub wielu WYDZIAŁACH. Każdy WYDZIAŁ może zatrudniać wielu PRACOWNIKÓW. PRACOWNIK WYDZIAŁ Każdy PRACOWNIK musi pracować w jednym lub wielu WYDZIAŁACH. Każdy WYDZIAŁ musi zatrudniać jednego lub wielu PRACOWNIKÓW. K. Bartecki, Inżynieria oprogramowania, V/24

25 Dlaczego nie modeluje się związków jeden do jednego obustronnie wymaganych? POJAZD nr identyf. marka rok produkcji : DOWÓD REJESTRACYJNY nr rejestracyjny nr dowodu rej. data rejestracji : Są one często różnymi perspektywami tej samej rzeczy, z innymi nazwami. Zwykle wystarczające jest w tym przypadku użycie jednej encji, z odpowiednimi atrybutami. POJAZD marka rok produkcji nr identyf. nr rejestracyjny nr dowodu rej. data rejestracji : K. Bartecki, Inżynieria oprogramowania, V/25

26 Kiedy w modelu związków encji pojawiają się związki wiele do wielu? POJAZD # nr rejestracyjny * marka * rok produkcji : naprawiany na miejscem naprawy STANOWISKO NAPRAW # nr stanowiska * czy jest kanał * czy jest podnośnik : Związki o tej liczebności pojawiają się często w początkowych fazach analizy i najczęściej sygnalizują związek, który nie jest w pełni przeanalizowany i wymaga dalszego rozłożenia. Rozłożenie związku wiele do wielu polega na znalezieniu tzw. encji intersekcji (przecięcia). K. Bartecki, Inżynieria oprogramowania, V/26

27 Encja intersekcji to encja powstała w wyniku eliminacji związku wiele do wielu między dwiema innymi encjami (referencyjnymi), często posiada swoje własne atrybuty, reprezentujące nowo odkryte szczegóły związku, często jest ona modelowana jako encja zależna (słaba): POJAZD # nr rejestracyjny * marka * rok produkcji : naprawiany na miejscem naprawy STANOWISKO NAPRAW # nr stanowiska * czy jest kanał * czy jest podnośnik : POJAZD # nr rejestracyjny * marka * rok produkcji : podlega dotyczy NAPRAWA # data naprawy o koszt naprawy wykonywana na miejscem STANOWISKO NAPRAW # nr stanowiska * czy jest kanał * czy jest podnośnik : Encja intersekcji Encje referencyjne K. Bartecki, Inżynieria oprogramowania, V/27

28 Encja intersekcji c.d. w encji intersekcji można dodać atrybut, pełniący rolę jej unikalnego identyfikatora, sprawia to, że encja intersekcji przestaje być encją słabą takie podejście daje wygodę w późniejszej implementacji: POJAZD # nr rejestracyjny * marka * rok produkcji : podlega dotyczy NAPRAWA # nr naprawy * data naprawy o koszt naprawy wykonywana na miejscem STANOWISKO NAPRAW # nr stanowiska * czy jest kanał * czy jest podnośnik : K. Bartecki, Inżynieria oprogramowania, V/28

29 Związek rekurencyjny przykład PRACOWNIK jest podwładnym jest przełożonym Każdemu PRACOWNIKOWI może zostać przyporządkowany inny PRACOWNIK, pełniący rolę jego przełożonego. Każdemu PRACOWNIKOWI może zostać przyporządkowanych wielu PRACOWNIKÓW, pełniących rolę jego podwładnych. K. Bartecki, Inżynieria oprogramowania, V/29

30 Modelowanie podtypów i nadtypów encji związek dziedziczenia Nadtyp to uogólniona encja, atrybuty nadtypu przechodzą na wszystkie jego podtypy, podtyp posiada swoje właściwości (atrybuty), a także wszystkie właściwości (atrybuty) odziedziczone po nadtypie, nie ma ograniczeń co do liczby podtypów encji. K. Bartecki, Inżynieria oprogramowania, V/30

31 Przykład związku dziedziczenia: nadtyp OSOBA # nr osoby * imię * nazwisko * adres Encja OSOBA jest nadtypem encji KLIENT i PRACOWNIK. podtypy Encje KLIENT i PRACOWNIK są podtypami encji OSOBA. KLIENT * data rejestracji * status o liczba punktów PRACOWNIK * pesel * data zatrudnienia * zarobki K. Bartecki, Inżynieria oprogramowania, V/31

32 Dziedziczenie wzajemnie wykluczające się: OSOBA # nr osoby * imię * nazwisko * adres OSOBA może być albo KLIENTEM, albo PRACOWNIKIEM (nie może być KLIENTEM i PRACOWNIKIEM jednocześnie) KLIENT * data rejestracji * status o liczba punktów PRACOWNIK * pesel * data zatrudnienia * zarobki K. Bartecki, Inżynieria oprogramowania, V/32

33 Podtypy encji mogą mieć własne związki z innymi encjami, przy czym automatycznie dziedziczą związki określone dla encji-nadtypu: z początkiem LOT NIEPLANOWANY do końcem LOTNISKO LOT początkiem z końcem do z wykorzystaniem przydzielony do LOT PLANOWANY na zaplanowana dla TRASA SAMOLOT K. Bartecki, Inżynieria oprogramowania, V/33

34 Nadmiarowe atrybuty KLIENT # nr klienta * nazwisko * imię : składa składane przez ZAMÓWIENIE # nr zamówienia * nazwisko * nazwa towaru * data zamówienia * liczba sztuk * kwota zamówienia dotyczy przedmiotem TOWAR # nr towaru * nazwa towaru * cena towaru : Atrybuty nazwisko oraz nazwa towaru zostały umieszczone w encji ZAMÓWIENIE nadmiarowo (błędnie), gdyż: atrybut nazwisko opisuje KLIENTA, i tylko w tej encji ma prawo się on znaleźć (i już się tam znajduje), atrybut nazwa towaru opisuje TOWAR, i tylko w tej encji ma prawo się on znaleźć (i już się tam znajduje), na diagramach encji nie uwzględnia się tzw. kluczy obcych (ang. foreign key, FK) pojęcie to nie występuje w modelu konceptualnym, pojawia się dopiero w implementacyjnym modelu relacyjnej bazy danych. K. Bartecki, Inżynieria oprogramowania, V/34

35 Związki nadmiarowe KLIENT # nr klienta * nazwisko * imię : składa składane przez ZAMÓWIENIE # nr zamówienia * data zamówienia * liczba sztuk * kwota zamówienia : dotyczy przedmiotem TOWAR # nr towaru * nazwa towaru * cena towaru : kupuje kupowany przez Związek pomiędzy encjami KLIENT oraz TOWAR jest nadmiarowy, gdyż z nazw ról wynika, iż powiela on informację już zawartą w związkach KLIENT-ZAMÓWIENIE oraz ZAMÓWIENIE-TOWAR K. Bartecki, Inżynieria oprogramowania, V/35

36 Zakładając, że każdemu z KLIENTÓW może być przypisany rabat na jeden, określony TOWAR: KLIENT # nr klienta * nazwisko * imię : składa składane przez ZAMÓWIENIE # nr zamówienia * data zamówienia * liczba sztuk * kwota zamówienia : dotyczy przedmiotem TOWAR # nr towaru * nazwa towaru * cena towaru : posiada rabat na sprzedawany z rabatem dla Tym razem bezpośredni związek pomiędzy encjami KLIENT oraz TOWAR jest uzasadniony, gdyż reprezentuje on informację inną od informacji zawartej w związkach KLIENT-ZAMÓWIENIE oraz ZAMÓWIENIE- TOWAR K. Bartecki, Inżynieria oprogramowania, V/36

37 Normalizacja danych to proces, mający na celu eliminację powtarzających się danych. Dzięki normalizacji uzyskujemy: elastyczność, konieczną do obsłużenia różnych wymagań funkcjonalnych, umożliwienie przeprowadzenia odwzorowania modelu encji w wiele różnych projektów baz danych. W dalszej części omówione zostaną cztery tzw. postaci normalne (PN): zerowa (0PN), pierwsza (1PN), druga (2PN), trzecia (3PN). K. Bartecki, Inżynieria oprogramowania, V/37

38 Zerowa postać normalna (0PN) Każda encja musi mieć zbiór atrybutów (związków), które w sposób unikalny określają jej wystąpienie. Przykład: diagram w 0PN WNIOSKODAWCA # NIP * Nazwisko * Imię * Imię ojca * Kod grupy uposażenia * Stawka wg grupy o Opis grupy uposażenia * Data złożenia wniosku * Treść wniosku * Kod typu wniosku * Opis typu wniosku K. Bartecki, Inżynieria oprogramowania, V/38

39 Ponieważ jeden WNIOSKODAWCA może składać wiele wniosków, więc niektóre z atrybutów mogą przyjmować więcej niż jedną wartość: WNIOSKODAWCA Przykładowe wartości Atrybuty wielowartościowe # NIP * Nazwisko * Imię * Imię ojca * Kod grupy uposażenia * Stawka wg grupy o Opis grupy uposażenia * Data złożenia wniosku * Treść wniosku * Kod typu wniosku * Opis typu wniosku Kowalski Zbigniew Wojciech 1D PLN młodszy referent , Wnioskuję o.., Niniejszym proszę.. C1, C7 Wniosek o zasiłek socjalny, Wniosek o refundację wczasów K. Bartecki, Inżynieria oprogramowania, V/39

40 Pierwsza postać normalna (1PN) Każdy atrybut może mieć tylko jedną wartość dla każdego wystąpienia jego encji w danej chwili czasu. Przejście z 0PN do 1PN: usunięcie atrybutów wielowartościowych i utworzenie dla nich nowej encji, identyfikator starej encji wchodził będzie w skład złożonego identyfikatora nowej encji (związek zależny). K. Bartecki, Inżynieria oprogramowania, V/40

41 Diagram w 1PN WNIOSEK # Kod typu wniosku # Data złożenia wniosku * Treść wniosku * Opis typu wniosku składany przez składa związek zależny wiele do jednego WNIOSKODAWCA # NIP * Nazwisko * Imię * Imię ojca * Kod grupy uposażenia * Stawka wg grupy o Opis grupy uposażenia Z diagramu wynika, że do jednoznacznego zidentyfikowania WNIOSKU konieczne jest podanie: kodu typu wniosku, daty złożenia wniosku, numeru NIP wnioskodawcy. K. Bartecki, Inżynieria oprogramowania, V/41

42 Druga postać normalna (2PN) (dotyczy encji z identyfikatorami złożonymi z kilku atrybutów) Wartość każdego atrybutu encji musi zależeć od całego identyfikatora tej encji (a nie tylko od niektórych atrybutów składających się na ten identyfikator). W naszym przykładzie wartość np. atrybutu Opis typu wniosku w encji WNIOSEK zależy jedynie od Kodu typu wniosku, a nie zależy od Daty złożenia wniosku i NIPu wnioskodawcy. Przejście z 1PN do 2PN: usunięcie wszystkich częściowo zależnych atrybutów i utworzenie dla nich nowej encji, skopiowanie części identyfikatora z encji pierwotnej (od której zależne są usunięte atrybuty) do tej nowej encji). K. Bartecki, Inżynieria oprogramowania, V/42

43 Diagram w 2PN WNIOSEK # Data złożenia wniosku * Treść wniosku składany przez składa WNIOSKODAWCA # NIP * Nazwisko * Imię * Imię ojca jest określonego * Kod grupy uposażenia * Stawka wg grupy o Opis grupy uposażenia klasyfikacją dla TYP WNIOSKU # Kod typu wniosku * Opis typu wniosku K. Bartecki, Inżynieria oprogramowania, V/43

44 Trzecia postać normalna (3PN) Wartość atrybutu encji nie może zależeć od wartości innego atrybutu, nie wchodzącego w skład jej identyfikatora. W naszym przypadku, wartości atrybutów Stawka wg grupy oraz Opis grupy uposażenia w encji WNIOSKODAWCA zależą jedynie od Kodu grupy uposażenia, a nie zależą od wartości atrybutu NIP, będącego identyfikatorem tej encji. Przejście z 2PN do 3PN: należy usunąć atrybuty niezależne od identyfikatora i wstawić je do nowej encji, identyfikatorem nowej encji staje się atrybut, od którego zależą jej pozostałe atrybuty. K. Bartecki, Inżynieria oprogramowania, V/44

45 Diagram w 3PN WNIOSEK # Data złożenia wniosku * Treść wniosku składany przez składa # NIP WNIOSKODAWCA * Nazwisko * Imię * Imię ojca jest określonego przydzielony do określona dla klasyfikacją dla GRUPA UPOSAŻENIA TYP WNIOSKU # Kod grupy uposażenia # Kod typu wniosku * Stawka wg grupy * Opis typu wniosku o Opis grupy uposażenia K. Bartecki, Inżynieria oprogramowania, V/45

46 Intuicyjna normalizacja Dobry analityk potrafi dojść do modelu związków encji w trzeciej postaci normalnej w sposób intuicyjny, tzn. bezpośrednio poprzez zidentyfikowanie encji, ich atrybutów i związków między encjami. K. Bartecki, Inżynieria oprogramowania, V/46

47 Typowe rozmieszczenie elementów diagramu związków encji UWAGA: notacja nieco różni się od omawianej na niniejszym wykładzie K. Bartecki, Inżynieria oprogramowania, V/47

48 Przykładowy diagram związków encji zbudowany w programie PowerDesigner Team Team number Speciality <pi> Division Idtf_5 <pi> Division number Division name Division address Idtf_1 <pi> 1..1 Belongs to <pi> 1..n Employee 0..n Member Employee number First name Last name Employee function Employee salary Idtf_2 <pi> Is member supervises of 1..n 0..1 <pi> 0..n Chief Is manager of 0..1 Is responsible for 0..n Subcontract Subcontract n Customer Customer number Customer name Customer address Customer activity Customer telephone Customer fax Idtf_3 <pi> <pi> Material Material number Material name Material type Idtf_7 <pi> composes composed of 0..n 0..n <pi> 1..1 Works on 0..n Participate Start date (par) End date (par) Is done n by Task 1..1 Belongs to 0..n Project Project number Project name Project label Idtf_4 <pi> <pi> Activity Start date (act) End date (act) Compose Task name Task cost <pi> Idtf_6 <pi> K. Bartecki, Inżynieria oprogramowania, V/48

49 Modelowanie związków encji podsumowanie Wyróżniamy istotne rzeczy (encje), o których informacja powinna być znana i/lub przechowywana. Dla każdej encji wyróżniamy szczegóły informacji (atrybuty), które powinny być znane i/lub przechowywane. Między encjami dodajemy związki, które nazywają istotne i ważne powiązania między nimi. Określamy, jak każde wystąpienie encji może być zidentyfikowane. Służyć może do tego pojedynczy atrybut encji, kilka jej atrybutów lub kombinacja atrybutów i związków. Staramy się, aby model encji był modelem w trzeciej postaci normalnej (normalizacja). K. Bartecki, Inżynieria oprogramowania, V/49