Projektowanie baz danych

Przegląd zagadnień

Cykle życia oprogramowania
Role i skład zespołu projektowego
Definiowanie wymagań dla systemu
Pojęcie encji, atrybutu i związku
Metody przekształcania związków
Model relacyjny
Podsumowanie
Laboratorium

Cykle życia oprogramowania

Główne etapy cyklu życia oprogramowania



Analiza,



Projektowanie,



Implementacja,



Testowanie,



Wdrożenie.

Cykle życia oprogramowania

Uproszczony cykl życia projektu budowy systemu

informatycznego

Model wodospadowy

Model spiralny

Model przyrostowy

Model przyrostowy określany również jako ewolucyjny, jest

pewnego rodzaju połączeniem dwóch poprzednich modeli.
W modelu tym analiza i ogólny projekt, mający na celu

wyodrębnić poszczególne składowe projektu, jest

wykonywany dla całego systemu przy zastosowaniu

modelu wodospadowego, natomiast kolejne etapy są

przeprowadzane przy użyciu modelu spirali.
Model ten przez swoją strukturę eliminuje wady zarówno

modelu wodospadowego, jak i spiralnego, przy

jednoczesnym zachowaniu zalet obu powyższych modeli.

Model z prototypem

Role i skład zespołu projektowego

Kierownik projektu
Analityk
Projektant
Programista
Tester
Wdrożeniowiec

Role i skład zespołu projektowego

Kierownik projektu

Kierownik projektu jest osobą, która czuwa nad całością projektu, a jej najważniejszym zdaniem
jest organizowanie i kontrolowanie pracy zespołu, kontaktowanie się z klientem oraz sprawdzanie
czy "wszystko idzie dobrze".

Analityk

Głównym zadaniem analityka jest zbudowanie modelu analitycznego (konceptualnego) systemu.
W tym celu musi on stale kontaktować się z klientem, dla którego budowane jest oprogramowanie
oraz dobrze zrozumieć jego potrzeby i orientować się w dziedzinie problemowej, której dotyczy
system.
Z całą pewnością nie jest to zadanie łatwe i oprócz rozległej wiedzy wymaga odpowiedniego
doświadczenia i umiejętności pracy z ludźmi. Dobrze wykonany model analityczny ma kluczowe
znaczenie dla powodzenia całego projektu. Błędy popełnione na tym etapie są później trudne do
usunięcia i zazwyczaj bardzo kosztowne.

Projektant

Zadaniem projektanta jest zbudowanie projektu systemu. Projekt systemu jest kolejnym modelem
systemu, ale na innym poziomie szczegółowości niż projekt wykonany przez analityka. Zawiera on
bowiem informacje o szczegółach implementacyjnych systemu. Projektant musi wobec tego mieć
odpowiednią wiedzę na temat systemu na którym będzie implementowana aplikacja i narzędzi,
które zostaną wykorzystane do jej budowy.

Role i skład zespołu projektowego

Programista

Zadaniem programisty jest zakodowanie projektu opracowanego przez projektanta.

Tester

Zadaniem testera jest przeprowadzenie różnorodnych testów aplikacji zanim trafi ona
do klienta.

Wdrożeniowiec

Wdrożeniowiec jest osobą, która przeprowadza uruchomienie (wdrożenie) aplikacji u
klienta. Powinien on również umieć przeszkolić użytkownika w użytkowaniu produktu,
a często jest też twórcą dokumentacji dla użytkownika.

W projekcie mogą też wystąpić inne role lub wymienione role mogą być łączone (np.

projektanta i programisty). Zależy to od konkretnych potrzeb, wielkości projektu i przyjętej

metody prowadzenia projektu. W naszym mini projekcie będziecie musieli przejść przez

wszystkie wymienione role z wyjątkiem roli wdrożeniowca.

Definiowanie wymagań dla systemu

Techniki badania wymagań użytkowników
Analiza dokumentacji
Wywiad
Ankieta
Analiza dokumentów (ciągle powstających)
Obserwacja (istniejącego systemu)

Definiowanie wymagań dla systemu

Techniki badania wymagań użytkowników Techniki

badania wymagań użytkowników

Do najczęściej stosowanych metod badań wymagań użytkowników

należą:



analiza dokumentacji,



ankieta,



analiza dokumentów (dynamicznych),



obserwacja.



Przy niewielkich projektach można stosować jedną z powyższych
metod, natomiast przy dużych systemach konieczne jest stosowanie
kilku technik jednocześnie w celu wnikliwego poznania wymagań
użytkowników.

Definiowanie wymagań dla systemu

Analiza dokumentacji



Zapoznanie się z dokumentacją, która funkcjonuje w danym
przedsiębiorstwie, do której zalicza się:



schemat organizacyjny,



dokumentację administracyjna,



specyfikacje stanowisk pracy,



opis procedur wewnętrznych,



dokumentacje szkoleniowe,



dokumentacje istniejących systemów.

Definiowanie wymagań dla systemu

Wywiad



Jest to najpopularniejsza metoda, w której analitycy
mogą zebrać i zweryfikować informacje o systemie,
zaakceptować rozwiązania, budowane jest zaufanie
użytkownika do systemu.



Najczęściej występujące problemy:



wywiad jest przeprowadzony z niekompetentnymi użytkownikami,



zadawane są złe pytania, a uzyskiwane odpowiedzi są

niepoprawne,



między analitykami a użytkownikami są niewłaściwe stosunki

(brak zaufania).

Definiowanie wymagań dla systemu

Ankieta



Przeprowadzana jest po wywiadzie (dla potwierdzenia
informacji).



Najczęściej występujące problemy przy ankiecie:



różna interpretacja pytań - niejednoznaczność odpowiedzi,



podczas ankiety odpowiedzi uzyskujemy tylko od niewielkiej

liczby ankietowanych,



nie wyjaśnia wszystkich wątpliwości.

Definiowanie wymagań dla systemu

Analiza dokumentów (ciągle powstających)



Analiza tych dokumentów, które są tworzone w firmie (raporty, zestawienia).

Taka analiza ma dać odpowiedź na następujące pytania:



Kto tworzy dokumentacje? - źródło.



Jak jest przygotowywany?



Jakie dane z dokumentacji są wykorzystywane?



Kto używa dokumentacji?



Kto wprowadza dane lub z nich korzysta?



Do jakich celów jest używany?



Jak jest przechowywany?



Jak długo jest przechowywany?



Informacja o obiegu istniejących dokumentów w firmie pozwala wyeliminować
niejasności i powtarzające się dokumenty

Definiowanie wymagań dla systemu

Obserwacja (istniejącego systemu)



Umożliwia zaobserwowanie elementów, które dla
użytkownika niekoniecznie są ważne (ale mogą być
istotne z punktu widzenia tworzonego SI).

Pojęcie encji, atrybutu i związku

Encja
Atrybut
Związek

Pojęcie encji



Encja jest to coś co istnieje, co odróżnia się od innych, o czym
trzeba mieć informację.



Zbiory encji reprezentują zbiór elementów występujących
w rzeczywistym świecie i każdy element tego zbioru musi posiadać
następujące cechy:



każdy element musi być unikalny, jednoznacznie określony, w celu

odróżnienia go od pozostałych,



każdy element musi odgrywać jakąś rolę w projektowanym systemie, nie

może zdarzyć się sytuacji, w której system może działać bez dostępu do
danego elementu,



każdy element powinien być opisany przez odpowiednią liczbę

atrybutów.



W diagramach ERD obiekt, encja jest reprezentowany przez
prostokąt, a jego nazwa powinna być rzeczownikiem.

Pojęcie atrybutu

Atrybut jest pewną własnością encji, o której chcemy przechowywać

informację.
Atrybut jest reprezentowany przez pewną wartość.
Na przykład encja Student może mieć atrybut Nazwisko reprezentowany

przez wartość Kowalski.
Wśród atrybutów encji wyróżniamy atrybut lub zbiór atrybutów, którego

wartość w sposób jednoznaczny identyfikuje instancję (egzemplarz)

encji.
Taki atrybut lub zbiór atrybutów nazywamy kluczem głównym encji.
Klucz główny oznacza się często na wykresach symbolem PK (ang.

Primary Key) umieszczanym obok nazwy atrybutu.
Drugim kluczem stosowanym w bazach relacyjnych jest klucz obcy.

Kluczem obcym nazywamy atrybut encji, który wskazuje na klucz

główny innej encji. Klucz obcy oznacza się często na wykresach

symbolem FK (ang. Foreign Key) umieszczanym obok nazwy atrybutu.

Atrybut

Związek

Bardzo ważnym elementem w modelu danych są związki pomiędzy encjami i warunki określające te

związku - elementy łączące encje między sobą.
Zdecydowana większość związków to powiązania stopnia drugiego - związki binarne, charakteryzujące

się tym, że w związku bierze udział dwóch uczestników (dwie encje).
Mogą występować także związki unarne (encja powiązana z samą sobą), jak również związki ternarne

(z trzema uczestnikami).
W zależności od tego, jakiego typu jest uczestnictwo encji w danym związku, możemy podzielić encje na

słabe lub regularne.
Encje słabe charakteryzują się całkowitym uczestnictwem w powiązaniu, to oznacza, że encja nie może

istnieć bez tego powiązania (np. encja Zamówienia nie może istnieć bez powiązania z encją Klienci).
Natomiast uczestnictwo encji regularnych w związku jest tylko częściowe, czyli encja może istnieć

samodzielnie bez powiązania (np. encja Klienci może istnieć bez powiązania z encją Zamówienia).

Bardzo istotnym czynnikiem określanym przy związkach jest moc powiązania, która definiuje się jako

maksymalną liczbę instancji jednej encji (wystąpień w danej encji), które mogą być powiązane z instancją

innej encji. Ze względu na wartość mocy możemy wyróżnić trzy typy powiązań:



jeden-do-jeden,



jeden-do-wiele,



wiele-do-wiele.

Związek jeden-do-wiele (jedno-wieloznaczny)

Najbardziej typowym rodzajem powiązania jest powiązanie jeden-do-

wiele, w którym pojedyncza instancja jednej encji może być połączona z

jedną lub wieloma instancjami drugiej encji.
Ze względu na swoją uniwersalność i małą kłopotliwość, ten typ

powiązania jest najczęściej stosowany .
Opcjonalnie przy powiązaniu jeden lub wiele może występować również

opcja żadne, oznaczana graficznie w postaci okręgu.

Związek wiele-do-wiele (wielo-wieloznaczny)

Powiązania tego typu występują równie często jak powiązania jeden do wielu,

jednak nie dają się bezpośrednio implementować w relacyjnych bazach danych.

Są one realizowane przy pomocy encji pośrednich (w modelu relacyjnym są to

tabele sprzęgające) powiązanych z encjami pierwotnymi przy pomocy powiązań

jeden do wielu.
W powiązaniu wiele-do-wiele encjami głównymi są encje pierwotne, natomiast

encją obcą jest relacja sprzęgająca, która zwiera klucze główne relacji

oryginalnej. Dlatego w powiązaniu jeden-do-wiele pomiędzy relacjami

pierwotnymi, a relacją obcą, po stronie relacji oryginalnej znajduje się strona

"jeden" powiązania jeden-do-wiele a po stronie relacji obcej znajduje się strona.

Związek

Związki unarne

Powiązania tego typu mają tylko jednego uczestnika, czyli relację, która jest

powiązana sama ze sobą. Powiązania są realizowane jest w podobny

sposób jak powiązania binarne, z tym że odnosi się to do jednej encji. Klucz

główny tej encji jest dodawany do tejże encji.
Powiązania unarne tak jak powiązania binarne mogą być różnej mocy. To

znaczy mogą występować powiązania jeden do wielu, które mogą być

opcjonalne po stronie "jeden". Ten typ powiązania jest stosowany przy

odwzorowywaniu struktur hierarchicznych.
Powiązania unarne mogą być również realizowane jako powiązania wiele do

wielu. Wtedy, podobnie jak przy powiązaniach binarnych, muszą być

modelowane przy użyciu tabeli sprzęgającej.

Związki ternarne

Są to powiązania w skład których wchodzą trzy związane ze sobą encje.
Powiązania te, podobnie jak powiązania wiele-do-wiele, nie mogą być

realizowane bezpośrednio w relacyjnych bazach danych.

Notacje związków

W praktyce spotkasz się z różnymi sposobami reprezentacji graficznej

związków (dla przykładu: w programach służących m.in. do projektowania

diagramów ERD takich jak Visio lub Rational Rose możliwe jest użycie kilku

różnych notacji).
Bodaj najpopularniejsza jest notacja czysto graficzna. Poniżej

zaprezentowano sposób, w jaki za pomocą notacji graficznej można

oznaczyć typ powiązania.

Metody przekształcania związków

Przekształcanie związków wielo-wieloznacznych
Przekształcanie związków ternarnych

Związki binarne wiele-do-wiele oraz związki ternarne nie są

implementowane w relacyjnych bazach danych. Dlatego

wymagają one pewnych przekształceń.

Przekształcanie związków wielo-wieloznacznych

Jeśli mamy związek binarny wielo-wieloznaczny, to należy wprowadzić dodatkową encję

oraz dwa nowe związki jednoznaczne. Nowa encja powinna wśród atrybutów zawierać klucze
obce odnoszące się do kluczy głównych dwóch pozostałych encji.

Przekształcanie związków ternarnych

Przy przekształcaniu związków ternarnych postępujemy podobnie jak w

wypadku związków wielo-wieloznacznych binarnych. Wprowadzamy wówczas
dodatkową encję oraz 3 nowe związki jednoznaczne.

Model relacyjny

Relacje i terminologia związana z modelem relacyjnym
Podstawowe działania na relacjach
Normalizacja

Relacje i terminologia związana z modelem relacyjnym

W klasycznym modelu relacyjnym pod pojęciem relacji rozumie się dwuwymiarową tablicę.

Relacja zdefiniowana jest poprzez tak zwany schemat relacji. Schemat relacji stanowi coś na kształt definicji tabeli.
Składa się on z nazwy relacji oraz zbioru atrybutów relacji.

Schemat relacji

Do definicji schematu relacji często dodaje się jeszcze

określenie dziedzin dla poszczególnych atrybutów

relacji.
Schemat relacji można rozumieć jako pustą tabelę ze

zdefiniowaną nazwą oraz nagłówkami kolumn.

Krotka

Kolejnym pojęciem jest krotka (inaczej rekord - ang. tuple lub record).
Krotką nazywamy każdy wiersz relacji, oczywiście z wyjątkiem wiersza

nagłówkowego.
Krotki mogą być zapisane w postaci uporządkowanego ciągu albo w

postaci zależności funkcyjnych.
Pierwszy z tych zapisów wymaga do prawidłowego odczytania krotki

znajomości definicji schematu relacji, jest natomiast znacznie krótszy.

Zbiór krotek

Zbiór krotek danej relacji tworzy instancję relacji (ang. recordset).
Warto zwrócić uwagę, że schemat relacji w czasie cyklu życia bazy

danych jest w zasadzie niezmienny (lub podlega bardzo rzadkim

zmianom), natomiast instancja relacji może zmieniać się w bazie

bardzo często.
W wielu implementacjach systemów baz danych można się spotkać

z różnym słownictwem dotyczącym modeli relacyjnych.
Na przykład w polskiej wersji MS Access pod pojęciem relacji

rozumie się związek (choć jak wiadomo, oba pojęcia oznaczają

zupełnie co innego), natomiast na określenie relacji stosuje się

pojęcie tabeli (te dwa pojęcia są akurat równoważne).
Trzeba się więc mieć na baczności, aby nie pogubić się w tej

plątaninie różnych pojęć stosowanych do określenia różnych

rzeczy.

Podstawowe działania na relacjach

Do podstawowych działań, które możemy wykonywać na relacjach

należą:



suma (ang. union),



różnica (ang. difference),



przecięcie (ang. engraving),



iloczyn kartezjański (ang. descartes-product),



rzut (ang. projection),



selekcja (ang. selection),



złączenie (ang. join),



złączenie teta (ang. teta join).

Suma relacji

Różnica relacji

Przecięcie relacji

Iloczyn kartezjański

Rzutowanie relacji

Selekcja

Złączenie

Złączenie teta

Normalizacja

Pierwsza postać normalna

Bez normalizacji

Normalizacja

Druga postać normalna

Normalizacja

Trzecia postać normalna

Podsumowanie

Cykle życia oprogramowania
Role i skład zespołu projektowego
Definiowanie wymagań dla systemu
Pojęcie encji, atrybutu i związku
Metody przekształcania związków
Model relacyjny

Laboratorium 1

• Ocena dokumentów wizji systemu

• Stworzenie diagramów ERD systemu

biblioteka

• Zapisanie dokumentów

• Omówienie poprawnego diagramu ERD