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 ludz
mi. Dobrze wykonany model analityczny ma kluczowe
znaczenie dla powodzenia całego projektu. Błędy popełnione na tym etapie są póz
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ć odpowiedz
na następujące pytania:
żð Kto tworzy dokumentacje? - z
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
Bez normalizacji
Pierwsza postać normalna
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